Alex Riesen wrote:
On linux-kernel, Nick Palmer wrote:
expects that a close call on a socket that another thread is
blocking in select and/or recvmsg on will cause select and/or
recvmsg to return with an error. Linux does not seem to do this.
It works always for stream sockets and does not at all (even with
shutdown, even using poll(2) or read(2) instead of select) for dgram
What domain (inet, local) are your sockets in?
What type (stream, dgram)?
We use both, though the breakage I was trying to fix was with a dgram
You are correct that it does not work for dgram sockets at all! I had
not noticed the difference between the two in the test case I wrote,
since I hadn't tested streams. Thanks for pointing that out. Note that
shutdown will cause a dgram socket to exit from a recv* call though, as
this is the workaround I am using right now. On Solaris close will do
the job. However when the recv from ends it returns 0, but does not set
errno, which indicates that there may be more data that can be retrieved
with another call to recv. On Solaris both shutdown and close cause
errno to be set.
There is no way then to cause a select on a dgram socket to break out at
all short of kludging some dgram packet transmission to cause it to happen.
Thanks for looking into the issue more,