Unix Domain Socket Limitation?
Tue Dec 1 02:14:58 GMT 2020
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!
More information about the Cygwin