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 17:03


| On Jan 15 16:33, Pierre A. Humblet wrote:
| > From: "Corinna Vinschen"
| > | 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?
|
| Oh, right.  I'm wondering how this is supposed to work at all in
| WinSock, if an application is using, say, blocking listening sockets and
| only wants to use event driven IO on the accepted sockets.  It looks
| like this is impossible without the danger of losing information.  In
| theory, if the peer sends exactly one packet, the accepting socket could
| wait forever for the packet if it arrived before WSAEventSelect has been
| called.  The FD_READ will never show up.  The alternative is I'm just
| exaggerating the potential problem.  I don't know.
|
| > 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.
|
| The event mask is not the problem since the mask given to WSAEventSelect
| is always the same in Cygwin, the whole set, regardless of how the
| socket is used.  The problem is that every socket needs its own
| event object so WSAEventSelect has to be called anyway.

I agree. It would be nice if the new event could be initialized to the value of the old.
Then we could have too many events for the new socket, but that's OK.

I am also wondering if we are misreading the doc. It says:
For FD_READ, FD_OOB, and FD_ACCEPT network events, network event recording
and event object signaling are level-triggered.
and it goes on to provide an example where the event is reenabled if there is still data.
The example given about the "clears the internal network event record" is of a
completely different nature.
The scenario you describe (one packet only, with a long delay between accept
and WSAEventSelect) could easily be tested to settle the matter.
Put a sleep before fdsock !

| What this means is, the accepted socket isn't in async mode anymore
| since the WSAEventSelect call in init_events has ended it.  So the async
| flag is erroneously preserved and we will have to apply this patch AFAICS.

At least we follow Linux :)

Pierre



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