Ove Kaaven wrote:
> function (which for sockets are sock_poll_event()). Do you know just
> exactly what changed in Linux to make that poll loop not function like
> it's supposed to?
>
> I don't think the above patch should break anything, but if it actually
> fixes something, then it's a sign that something else might be wrong.
I think I've found the specific kernel change that caused the change in behaviour.
In linux/net/ipv4/tcp.c:
...
...
* NOTE. Check for TCP_CLOSE is added. The goal is to prevent
* blocking on fresh not-connected or disconnected socket. --ANK
*/
if (sk->shutdown == SHUTDOWN_MASK || sk->state == TCP_CLOSE)
mask |= POLLHUP;
The net effect is that a not-yet-connected TCP socket will return a POLLHUP after a
poll(). In wine/server/sock.c, the sock_poll_event() function looks at POLLHUP even
for sockets that are in the process of establishing connections. A spurious POLLHUP
causes it to call set_select_events(&sock->obj, -1), propagating a non-existing
error condition to the Wine process.
It seems that the right solution is to ignore POLLHUP for sockets that are in
WS_FD_CONNECT state. Does that sound reasonable?
Berend
