Corinna Vinschen corinna-cygwin@cygwin.com
Fri Jan 15 20:34:00 GMT 2010

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?


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-patches mailing list