On 11/30/2020 1:26 PM, Norton Allen wrote:
On 11/30/2020 1:14 PM, Ken Brown wrote:
I can reproduce the hang, and it happens if I use the new AF_UNIX code also.
But what I'm seeing (at least with the new code) isn't exactly what you describe.
When the server's first select call returns, accept succeeds. The server then
calls select a second time, and that call doesn't return. I haven't checked
yet to see what's going on in the client, and I may not get to that for a while.
That's good news, and seems to be consistent with my theory that it is some sort
of race condition that might be particularly sensitive to system-specific
timing. I am compiling cygwin1.dll now.
Hi Norton,
I think there's a mistake in your test program. Shouldn't client_pselect() be
waiting for the socket to be write-ready rather than read-ready? Here's a quote
from the Posix page for 'connect':
If the connection cannot be established immediately and O_NONBLOCK is set for
the file descriptor for the socket, connect() shall fail and set errno to
[EINPROGRESS], but the connection request shall not be aborted, and the
connection shall be established asynchronously....
When the connection has been established asynchronously, pselect(), select(),
and poll() shall indicate that the file descriptor for the socket is ready for
writing.
Ken
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
