Skip to contentSkip to conversation

select implementation not POSIX compliant?

DISCUSSION Manfred Spraul 3 participants 3 messages Aug 11, 2004 – Aug 13, 2004

lore
Share & tools
lore
#0 lore raw
Quoted 7 lines · Nick

Furthermore, a call to close and then select in the same thread blocks while the other thread is still in select, which has a very large surprise factor, since the code would work were it not for the other select.

Could you post the test case for this behavior: I assume your test app is buggy: a select call that is executed after close returned must return EBADF, everything else would be a bug.

Regarding your main point: The return result from select/poll is undefined in Linux if you close a descriptor while another thread polls or selects it. This is consistent with the behavior of other Unices - for example HP UX kills the process if you replace a descriptor that is being polled with dup2.

--
Manfred

#1 lore raw
Quoted 3 lines · Manfred Spraul

Could you post the test case for this behavior: I assume your test app is buggy: a select call that is executed after close returned must return EBADF, everything else would be a bug.

Actually Solaris and Linux are consistent in terms of the behavior of select in this respect. I suspect that the first select is blocking the socket from being used at all, so the second select can't tell that it is closed.

Quoted 6 lines

Regarding your main point: The return result from select/poll is undefined in Linux if you close a descriptor while another thread polls or selects it.
This is consistent with the behavior of other Unices - for example HP UX kills the process if you replace a descriptor that is being polled with dup2.

Right, hence my feeling that select is over all fairly broken. The big difference between Solaris and Linux though is that close will call recv* calls to return on Solaris, and close doesn't do that on Linux. The work around is to use shutdown on Linux before calling close. This also works on Solaris, though it makes the recv set errno differently.

Thanks for looking at this issue,
-Nick

#2 lore raw
Quoted 4 lines · Nick Palmer

Actually Solaris and Linux are consistent in terms of the behavior of select in this respect. I suspect that the first select is blocking the socket from being used at all, so the second select can't tell that it is closed.

The objects are refcounted so the socket hasn't gone away until the point the select returns.

Alan