9fa516ef   
   From: grahn+nntp@snipabacken.se   
      
   On Tue, 2010-02-23, David Schwartz wrote:   
   > On Feb 22, 3:39 pm, Jorgen Grahn  wrote:   
   >   
   >> which mirrors the discussion here, except most admitted that POSIX   
   >> says select on blocking sockets works reliably.  I guess the best   
   >> summary is what Mark Mielke suggested as Linux documentation:   
   >   
   > POSIX is really quite clear that it doesn't make such a guarantee. It   
   > is quite clear that 'select' simply reports current status and that it   
   > does not guarantee future results. It uses very natural terminology to   
   > do this.   
      
   In that Linux kernel mailing list thread mentioned above, everyone (or   
   possibly just almost everyone) seemed to disagree with your   
   interpretation.  Even the big group (including several well-known   
   programmers) who thought little of POSIX and like you recommended   
   O_NONBLOCK sockets.   
      
   > For example, one could describe a successful return from "access"   
   > checking readability as meaning that an attempt to open the file for   
   > reading wouldn't fail with a permissions error. But this in no way   
   > implies that an actual subsequent open will not in fact fail.   
      
   That one is immediately obvious, because it's not talking about   
   resources/state owned by the process.   
      
   What you argue about select() is more like this:   
      
     "open(2) fails or gives you a file descriptor. But that's just the   
     current status -- when you try to use it it might have closed again."   
      
   Which is clearly not true.   
      
   >>     'The Linux developers believe that the use of select() with   
   >>     blocking file descriptors is invalid or not recommended, and have   
   >>     chosen not to ensure that this use of system calls is reliable.'   
   >   
   > Because it is impossible to ensure that this use of system calls is   
   > reliable. I'm not sure it's worth going into the detailed analysis   
   > here [...]   
      
   No; we have beaten the subject half to death, and still that LKML   
   thread did a much better job.  All arguments we have used were used   
   there (even though they mostly talked about one specific case: a   
   datagram with a bad checksum over UDP).   
      
   One last comment though:   
      
   > Consider:   
   >   
   > 1) Thread A calls 'select', gets a writability hit for socket 12.   
   >   
   > 2) Thread B calls 'write' on socket 12.   
      
   That one was used on the LKML and refuted, too.  People who do such   
   things get what they deserve (and I'm not even sure I care what POSIX   
   has to say about it).  You'd need an example which doesn't involve   
   multiple threads sharing fds without synchronization.   
      
   (I haven't really read your followup example though.)   
      
   /Jorgen   
      
   --   
     // Jorgen Grahn    O  o   .   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)