Urgent need for advice: POLLHUP and sockets
Martin Wilck
Martin.Wilck at fujitsu-siemens.com
Wed Apr 17 04:03:00 CDT 2002
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:Martin.Wilck at Fujitsu-Siemens.com
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
More information about the wine-devel
mailing list