This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: dup3/O_CLOEXEC/F_DUPFD_CLOEXEC


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


| On Jan 15 21:22, Corinna Vinschen wrote:
| > On Jan 15 15:04, Pierre A. Humblet wrote:
| > > 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.
| >
| > I have no problem to change the SOCK_NONBLOCK stuff as you proposed.
| >
| > I don't like the idea to introduce such a new flag for ASYNC which
| > doesn't exist on Linux, though.  How important is the async mode anyway?
| > Will we really get any problems with existing apps if we switch to the
| > Linux behaviour for async?
|
| Oh, hang on.  I guess we should better stick to the BSD behaviour.
| Any call to WSAAsyncSelect or WSAEventSelect clears Winsock's internal
| network event queue.  This could lead to connection errors.  Given
| that, the switch to a specific mode should stay the responsibility
| of the application, shouldn't it?

I know next to nothing about this but notice that :accept4 calls fdsock
which calls init_events which calls WSAEventSelect .
Isn't that what you want to avoid?
On the other hand I don't see how you can avoid it given this:

Any WSAEventSelect association and network events selection set for the listening socket apply 
to the accepted socket. For example, if a listening socket has WSAEventSelect association of 
hEventObject with FD_ACCEPT, FD_READ, and FD_WRITE, then any socket accepted on that listening 
socket will also have FD_ACCEPT, FD_READ, and FD_WRITE network events associated with the same 
hEventObject. If a different hEventObject or network events are desired, the application should 
call WSAEventSelect, passing the accepted socket and the desired new information.

Pierre




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]