Well, I think the problem is (possibly) more a quirk of how the test is written than an indication of an actual problem:
The test in question uses SSL.File in blocking mode, and not through the TCP stack.
The client and server SSL.File are created, connected by a pipe and then connect/accept() ed. A thread for each is started. The server thread write()s its data followed immediately by close(). The client thread first checks is_open() before reading any data, and this is where the tests are failing. I am reasonably sure (but have not tested beyond scanning the SSL debug) that there is data is sitting in the SSL.File to be read regardless of whether the “network side” is open or not.
What the client side of the test seems to be trying to check is that the handshake worked and that the SSL.File is able to communicate with the server. It does appear to be working, it’s just all happening too fast for the client side to detect that. A secondary part of the problem is the facade that SSL.File is just like a regular Stdio.File is breaking down a bit: is_open() is false, but it’s really more like “is open for writing” but true for “is open for reading”.
Thoughts?
On Dec 3, 2020, at 2:18 AM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum 10353@lyskom.lysator.liu.se wrote:
I think the client should be able to handle the server not sleeping. In the wild it's impossible for the server to know how much to sleep since it will depend on both the network connection and which client it is. Also, the client should work with non-pike servers, which might not sleep.
Is the problem that not all the data is submitted to TCP/IP, or that the client somehow aborts before receiving it from the IP stack?