----- 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