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