Author pitrou
Recipients lekma, pitrou, r.david.murray
Date 2010-01-12.18:05:50
SpamBayes Score 6.37719e-11
Marked as misclassified No
Message-id <1263319552.42.0.97170209947.issue7523@psf.upfronthosting.co.za>
In-reply-to
Content
Looking at it again, there's the question of accept() behaviour. In the original code, it will call internal_setblocking() on the new fd if the listening socket is non-blocking. In the new code, if SOCK_NONBLOCK is defined it will not call any OS function to set the new fd in non-blocking mode.

Here is what the man page has to say:

       On Linux, the new socket returned by accept() does not inherit file status  flags  such  as
       O_NONBLOCK and O_ASYNC from the listening socket.  This behavior differs from the canonical
       BSD sockets implementation.  Portable programs should not rely on inheritance or non-inher‐
       itance  of  file  status  flags  and always explicitly set all required flags on the socket
       returned from accept().

Linux has defined accept4() precisely for this purpose:

       If flags is 0, then accept4() is the same as accept().  The following values can be bitwise
       ORed in flags to obtain different behavior:

       SOCK_NONBLOCK   Set the O_NONBLOCK file status flag  on  the  new  open  file  description.
                       Using this flag saves extra calls to fcntl(2) to achieve the same result.

       SOCK_CLOEXEC    Set  the  close-on-exec  (FD_CLOEXEC) flag on the new file descriptor.  See
                       the description of the O_CLOEXEC flag in open(2) for reasons why  this  may
                       be useful.
History
Date User Action Args
2010-01-12 18:05:52pitrousetrecipients: + pitrou, r.david.murray, lekma
2010-01-12 18:05:52pitrousetmessageid: <1263319552.42.0.97170209947.issue7523@psf.upfronthosting.co.za>
2010-01-12 18:05:51pitroulinkissue7523 messages
2010-01-12 18:05:50pitroucreate