lkml.org 
[lkml]   [2004]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
Subjectselect implementation not POSIX compliant?
From
Hey all,

I am working on porting some software from Solaris to Linux 2.6.7. I have
run into a problem with the interaction of select and/or recvmsg and close
in our multi-threaded application. The application 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. (I also verified that the same issue exists in Linux
2.4.25, just to be sure it wasn't introduced in 2.6 in case you were
wondering.)

I found this thread:
http://www.ussg.iu.edu/hypermail/linux/kernel/0006.3/0414.html
which indicates that we must call shutdown first in order to get the
desired behavior, which works as described. However this doesn't seem to
be a POSIX compliant implementation by my read of the POSIX specification
for select. (The specification for recvmsg doesn't specifically talk about
this condition, so I can accept that the implementation on Linux is
compliant for recvmsg, even if the behavior is a bit surprising to me, but
not for select.)

From the POSIX specification for select from
http://www.unix.org/single_unix_specification/:

A descriptor shall be considered ready for reading when a call to an input
function with O_NONBLOCK clear would not block, whether or not the
function would transfer data successfully.
<snip>
If a descriptor refers to a socket, the implied input function is the
recvmsg() function with parameters requesting normal and ancillary data,
such that the presence of either type shall cause the socket to be marked
as readable.

I have a test case (email me off list if you want a copy) that shows that
a call to the input function does not block, but instead returns an error
after a close call, yet the select called before the close continues to
block. 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.

This is certainly a large enough difference from Solaris to cause our
POSIX application not to work on Linux, and I imagine I'm not the only one
that has experienced problems with this implementation. Is there a good
argument for why it has been implemented this way? It is certainly less
than intuitive.

Thanks for addressing this issue,
-Nick
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.128 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site