bf71ff62   
   From: grahn+nntp@snipabacken.se   
      
   On Tue, 2010-03-02, David Schwartz wrote:   
   > On Mar 1, 5:39 pm, Rick Jones  wrote:   
   ...   
   >> (FWIW, I think that was the motivation behind the odd "ENOBUFS" return   
   >> of accept() in HP-UX 11 - because all those pesky enterprise customers   
   >> who were accustomed to a particular behaviour - not getting stuck in   
   >> an accept() call - wanted that maintained) HP-UX 11 was an "upgrade"   
   >> to previous HP-UX versions and so backwards compatability to   
   >> semantics, even those in grey areas of what few standards there were   
   >> were rather important).   
   >   
   > See my other post on why I can't follow the logic on this. If an   
   > application was specifically coded with this issue in mind, why   
   > wouldn't it just set the socket non-blocking, which is portable and   
   > guaranteed to work by standards? If the intention was to fix code "by   
   > accident", what about code that does the most logical thing when it   
   > gets an "ENOBUFS" error? (These things include load shedding in a   
   > cluster and sleeping and then calling 'recvmsg' again in a non-   
   > clustered environment.)   
      
   One last comment here. Ironically, it's Stevens' answer to my initial   
   question -- it was in my bookshelf all the time, complete with code to   
   trigger the block.   
      
   Unix Network Programming, 2nd ed, vol 1, section 5.11, "Connection   
   Abort before accept() Returns":   
      
       Unfortunately, what happens to the aborted connection is   
       implementation-dependent. Berkeley-derived implementations handle   
       the aborted connection completely within the kernel, and the   
       server never sees it.  Most SVR4 implementations return an errno   
       of EPROTO, but Posix.1g specifies that the return must be   
       ECONNABORTED instead.   
      
   And then in 15.6 he explains the actual select problem, and recommends   
   non-blocking listening sockets. He refers to the Berkeley behavior as   
   "a bug", but accepts it as a fact of life.   
      
   So it seems to me HP-UX 11 had a choice between three behaviours and   
   chose a fourth. But the important lesson is that there *was* a   
   traditional solution which didn't mean blocking -- not blocking wasn't   
   some weird new HP-UX invention.   
      
   /Jorgen   
      
   PS I'm not trying to push Stevens as the golden standard, but it *is* a   
      widely used and respected work on the subject.   
      
   --   
     // Jorgen Grahn    O  o   .   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)