On Tue, 16 Apr 2002, Ove Kaaven wrote: > Sounds like one we've discussed and resolved before.
Sorry, that was before my times :) Anyway, I think there are open issues yet. > Yes, it's still valid to read, but no more data will arrive on the socket, > so the only thing you'll read is data that's already waiting in the kernel > buffers. There's no reason to continue actively polling. Yes but read events must be signalled and/or async reads scheduled after POLLHUP was received. > > However, if an application uses asynchronous IO (or only asynchronous > > notification via WSAAsyncSelect() or WSAEventSelect()), this also inhibits > > reception of POLLIN events which can perfectly well occur if there are > > still unread data in the kernel buffers. Thus the app will never notice > > that there is still data to be read. > > Not quite. No more data will arrive on the socket when it's in POLLHUP > state, so there's no need for the server to poll. > Instead, it notifies the > app that there's still data remaining to be read next time it reads from > the socket (this is what the "check whether condition is satisfied > already" case in sock_reselect does, it explicitly does a poll even if the > socket is removed from the main polling loop, in order to check for > remaining data). Hmm - this code went away with CVS version 1.28 of sock.c. Perhaps we need to reintroduce it somehow. > Sending the app new FD_READ events only after it has read > old data is a documented Windows feature; further FD_READ events are held > back until the app reads old data, and this is what the wineserver > implements, especially in the POLLHUP case. Sorry, I cannot see what you are talking about, not in the current CVS version. All that happens after a read() is issued is _enable_event (FD_READ, 0, 0), and that clears the pending mask for FD_READ. How would that ever be set again, and FD_READ signalled ? (Consider an app that does not read _all_ remaining data after FD_CLOSE but only part of it and then issues further asynchronous read()s). The key probably is that sock_poll_event() was called from sock_reselect() if the "condition is satisfied", which is no longer the case in 1.28. Thanks for replying anyway, Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
