On 11/30/2020 6:19 PM, Ken Brown wrote:
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.
Yes, you are correct. In fact I had already fixed that bug on another
branch, then forgot to update it on this one. I also noticed another bug
in calculating width. Now I am not getting the blocking behavior but
instead getting the wrong bits set in select(). I think I'd better pick
this up in the morning when I am thinking straight!
--
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
