dup3/O_CLOEXEC/F_DUPFD_CLOEXEC

Pierre A. Humblet phumblet@phumblet.no-ip.org
Fri Jan 15 20:05:00 GMT 2010


----- Original Message ----- 
From: "Corinna Vinschen" 
To: <cygwin-patches>
Sent: Friday, January 15, 2010 10:42

| On Jan 14 17:09, Corinna Vinschen wrote:
| > On Jan 14 08:39, Pierre A. Humblet wrote:
| > > 
| > > For the same reason we should also have SOCK_CLOEXEC, and
| > > SOCK_NONBLOCK while we are at it. I would use them in minires.
| > 
| > Sure, but probably not yet, as far as my hack time is concerned.  But
| > of course SHTDI, PTC, and all that.  I'd be glad for it, actually.
| 
| It was simpler than I anticipated.  I just applied a patch to implement
| accept4, and SOCK_NONBLOCK as well as SOCK_CLOEXEC for socket,
| socketpair and accept4.
 
Thanks, I was just looking into that.
I see an issue with accept/accept4 and was going to ask you how to handle it.

Before your changes in Cygwin the socket returned by accept had the same blocking
(and async) property as the listening socket.
Apparently this conforms to BSD but not to Linux (even old versions without accept4),
http://www.kernel.org/doc/man-pages/online/pages/man2/accept.2.html
POSIX is silent on the topic.

After your changes the new socket is non-blocking if either the listening socket was
non-blocking or SOCK_NONBLOCK is specified. This does not conform to Linux.

Why not have accept4 conform to Linux but keep the old behavior of accept by
changing accept in net.cc to 
res = fh->accept4 (peer, len, fh->is_nonblocking () ? SOCK_NONBLOCK : 0);

There is a similar Linux discrepancy with async_io. 

Pierre



More information about the Cygwin-patches mailing list