[lkml]   [2001]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PROBLEM: select() says closed socket readable
David Schwartz wrote:

> No, because 'select' is defined to work the same on both blocking and
> non-blocking sockets. Roughly, select should hit on read if a non-blocking
> read wouldn't return 'would block'.

Which may be the root of the problem. Linux seems to consider that
select indicates "would not block", whereas Solaris et. al. use
"ready to read". (The difference seems to exist in man pages too)
Clearly an unconnected socket "would not block" but is not
"ready to read".

> If you think about the cases where someone might actually do this, odds are
> you want the application's error handling code to launch. That won't happen
> if you never break out of select. However, if you do break out of select, do
> a read, and get an error, the problem will then be handled, rather than
> ignored.

No. If there is a correct behaviour defined in a standard we should
do that. Otherwise we should do what other systems do _unless_ there
is a clear benefit to doing something else. In this case doing
something else appears to create porting problems and confusion over
what select(2) means without any clear benefit.

So, we're back to the beginning: justify with reference or reason :-).


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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