The problem is that poll returns POLLHUP when a socket isn't connected, then wine ignores the socket and it's events .. I realize this has been known for a some time(since linux 2.4), but why hasn't it been fix? Doesn't this effect a lot of non-blocking socket applications?
Daniel Walker
Daniel Walker wrote:
The problem is that poll returns POLLHUP when a socket isn't connected,then wine ignores the socket and it's events .. I realize this has been known for a some time(since linux 2.4), but why hasn't it been fix? Doesn't this effect a lot of non-blocking socket applications?
Can you define the problem a bit more? Do you mean you get a POLLHUP *while waiting* for connection? - Dan
Dan Kegel wrote:
Daniel Walker wrote:
The problem is that poll returns POLLHUP when a socket isn't connected,then wine ignores the socket and it's events .. I realize this has been known for a some time(since linux 2.4), but why hasn't it been fix? Doesn't this effect a lot of non-blocking socket applications?
Can you define the problem a bit more? Do you mean you get a POLLHUP *while waiting* for connection?
No, I mean that a socket is created using socket() then, say, ioctl() is run on it. ioctl() then ,through the wineserver, runs sock_reselect() then poll() returns POLLHUP in revents and the wineserver stop watching the socket .. Since most non-blocking applications run socket() then ioctl() I would think that several applications would be effected..
Daniel Walker
Daniel Walker wrote:
Dan Kegel wrote:
Daniel Walker wrote:
The problem is that poll returns POLLHUP when a socket isn't connected,then wine ignores the socket and it's events .. I realize this has been known for a some time(since linux 2.4), but why hasn't it been fix? Doesn't this effect a lot of non-blocking socket applications?
Can you define the problem a bit more? Do you mean you get a POLLHUP *while waiting* for connection?
No, I mean that a socket is created using socket() then, say, ioctl()is run on it. ioctl() then ,through the wineserver, runs sock_reselect() then poll() returns POLLHUP in revents and the wineserver stop watching the socket .. Since most non-blocking applications run socket() then ioctl() I would think that several applications would be effected..
When I run the following program, I get n=0 consistently on linux 2.2 or 2.4. Did I misunderstand the test condition?
#include <stdio.h> #include <sys/poll.h>
main() { int fd; struct pollfd pfds[1]; int n;
fd = socket(); pfds[0].fd = fd; pfds[0].events = POLLIN|POLLOUT; n = poll(pfds, 1, 0); printf("n %d, revents %x\n", n, pfds[0].revents); }
Daniel Walker wrote:
Dan Kegel wrote:
Daniel Walker wrote:
The problem is that poll returns POLLHUP when a socket isn't connected,then wine ignores the socket and it's events .. I realize this has been known for a some time(since linux 2.4), but why hasn't it been fix? Doesn't this effect a lot of non-blocking socket applications?
Can you define the problem a bit more? Do you mean you get a POLLHUP *while waiting* for connection?
No, I mean that a socket is created using socket() then, say, ioctl()is run on it. ioctl() then ,through the wineserver, runs sock_reselect() then poll() returns POLLHUP in revents and the wineserver stop watching the socket .. Since most non-blocking applications run socket() then ioctl() I would think that several applications would be effected..
This problem has already been documented. The Linux Kernel 2.4 changed the way poll() works. But wine apparently hasn't been updated to work with the way poll() currently works .. Under some situations an application will open a socket then set it as non-blocking with ioctl() , while all that is happening the wineserver gets a POLLHUP (btw, I'm talking about revents) from poll() and subsequently ignores all other event on the socket..
the issue is discussed at the bottom of this WWN ..
On Thu, 16 Aug 2001, Daniel Walker wrote:
The problem is that poll returns POLLHUP when a socket isn't connected, then wine ignores the socket and it's events .. I realize this has been known for a some time(since linux 2.4), but why hasn't it been fix? Doesn't this effect a lot of non-blocking socket applications?
No, since this problem was fixed half a year ago, it shouldn't affect anything.
Ove Kaaven wrote:
On Thu, 16 Aug 2001, Daniel Walker wrote:
The problem is that poll returns POLLHUP when a socket isn't connected,then wine ignores the socket and it's events .. I realize this has been known for a some time(since linux 2.4), but why hasn't it been fix? Doesn't this effect a lot of non-blocking socket applications?
No, since this problem was fixed half a year ago, it shouldn't affect anything.
It must not be completely fixed.. Where is the patch that fixed it?
Daniel Walker
On Fri, 17 Aug 2001, Daniel Walker wrote:
Ove Kaaven wrote:
On Thu, 16 Aug 2001, Daniel Walker wrote:
The problem is that poll returns POLLHUP when a socket isn't connected,then wine ignores the socket and it's events .. I realize this has been known for a some time(since linux 2.4), but why hasn't it been fix? Doesn't this effect a lot of non-blocking socket applications?
No, since this problem was fixed half a year ago, it shouldn't affect anything.
It must not be completely fixed.. Where is the patch that fixed it?
http://www.winehq.com/cvsweb/wine/server/sock.c.diff?r1=1.11&r2=1.12
Ove Kaaven wrote:
On Fri, 17 Aug 2001, Daniel Walker wrote:
Ove Kaaven wrote:
On Thu, 16 Aug 2001, Daniel Walker wrote:
The problem is that poll returns POLLHUP when a socket isn't connected,then wine ignores the socket and it's events .. I realize this has been known for a some time(since linux 2.4), but why hasn't it been fix? Doesn't this effect a lot of non-blocking socket applications?
No, since this problem was fixed half a year ago, it shouldn't affect anything.
It must not be completely fixed.. Where is the patch that fixed it?http://www.winehq.com/cvsweb/wine/server/sock.c.diff?r1=1.11&r2=1.12
This fixes the problem that I'm seeing .. Any version of Bearshare seem to be effected ..
Daniel Walker
Index: sock.c =================================================================== RCS file: /home/wine/wine/server/sock.c,v retrieving revision 1.18 diff -u -r1.18 sock.c --- sock.c 2001/05/14 20:09:39 1.18 +++ sock.c 2001/08/17 12:58:03 @@ -548,7 +548,7 @@ sock->hmask &= ~req->mask; sock->state |= req->sstate; sock->state &= ~req->cstate; - sock_reselect( sock ); +/* sock_reselect( sock ); */
/* service trigger */ if (req->mask & WS_FD_SERVEVENT)
On Fri, 17 Aug 2001, Daniel Walker wrote:
This fixes the problem that I'm seeing .. Any version of Bearshare seem to be effected ..
Well, this is not a correct patch of course (but you probably already knew that), but if this fixes something, I'd like to know what and why, as sock_reselect should never do a poll() unless sock->state is set, and sock->state should (in theory) not be set before a connect() or listen() is done on the socket. Do a --debugmsg +server,+winsock, please?
Ove Kaaven wrote:
On Fri, 17 Aug 2001, Daniel Walker wrote:
This fixes the problem that I'm seeing .. Any version of Bearshare seemto be effected ..
Well, this is not a correct patch of course (but you probably already knew that), but if this fixes something, I'd like to know what and why, as sock_reselect should never do a poll() unless sock->state is set, and sock->state should (in theory) not be set before a connect() or listen() is done on the socket. Do a --debugmsg +server,+winsock, please?
From the trace it looks like sock->state is set the WD_FD_NONBLOCKING . enable_socket_event() set's the sock->state to non-blocking then calls sock_reselect.
Daniel Walker
On Sat, 18 Aug 2001, Daniel Walker wrote:
Ove Kaaven wrote:
On Fri, 17 Aug 2001, Daniel Walker wrote:
This fixes the problem that I'm seeing .. Any version of Bearshare seemto be effected ..
Well, this is not a correct patch of course (but you probably already knew that), but if this fixes something, I'd like to know what and why, as sock_reselect should never do a poll() unless sock->state is set, and sock->state should (in theory) not be set before a connect() or listen() is done on the socket. Do a --debugmsg +server,+winsock, please?
From the trace it looks like sock->state is set the WD_FD_NONBLOCKING . enable_socket_event() set's the sock->state to non-blocking then calls sock_reselect.
Aha. Then you'd probably want something like this, then?
Index: server/sock.c =================================================================== RCS file: /home/wine/wine/server/sock.c,v retrieving revision 1.18 diff -u -r1.18 sock.c --- server/sock.c 2001/05/14 20:09:39 1.18 +++ server/sock.c 2001/08/18 15:00:53 @@ -84,7 +84,7 @@
if (sock->obj.select == -1) { /* previously unconnected socket, is this reselect supposed to connect it? */ - if (!sock->state) return; + if (!(sock->state & ~WS_FD_NONBLOCKING)) return; /* ok, it is, attach it to the wineserver's main poll loop */ add_select_user( &sock->obj ); }
That seems to work .. Are there any other place where this POLLHUP problem might show it's teeth?
Daniel Walker
Ove Kaaven wrote:
Aha. Then you'd probably want something like this, then?
Index: server/sock.c
RCS file: /home/wine/wine/server/sock.c,v retrieving revision 1.18 diff -u -r1.18 sock.c --- server/sock.c 2001/05/14 20:09:39 1.18 +++ server/sock.c 2001/08/18 15:00:53 @@ -84,7 +84,7 @@
if (sock->obj.select == -1) { /* previously unconnected socket, is this reselect supposed to connect it? */
if (!sock->state) return;
if (!(sock->state & ~WS_FD_NONBLOCKING)) return; /* ok, it is, attach it to the wineserver's main poll loop */ add_select_user( &sock->obj );
On Sat, 18 Aug 2001, Daniel Walker wrote:
That seems to work .. Are there any other place where this POLLHUP problem might show it's teeth?
Doubt it. The previous patch concentrated all the issues of POLLHUP into that "if (...) return;" test, where it returns (and hence does not get polled) when the socket is still in the unconnected state where Linux may return POLLHUP... the only issue is that there may be other flags than WS_FD_NONBLOCKING that may mask the unconnected state, but I don't think so (for instance, UDP sockets does not have to be connected to be polled).
-
Dan Kegel -
Daniel Walker -
Ove Kaaven