On Wed, 17 Apr 2002, Ove Kaaven wrote:
I can send you the sock.c I have if you wish, but you may be able to check out an earlier revision yourself.
Yeah, I checked out 1.27 and am stuying it right now.
If this code path was removed, then you'll probably have to put it back in.
I guess I need to do some more things for the overlapped IO, but basically you are right.
I have 2 questions:
1. In the code you're talking about, there is a potential mutual recursion because sock_get_poll_events calls sock_reselect, which may in turn call sock_get_poll_events. I understand that infinite recursion is prevented by handling the sock->hmask field, but I wonder whether it is necessary at all that sock_get_poll_events calls sock_reselect() and not only set_select_events(sock_get_poll_events()) ? I'd prefer a solution where no call sequence sock_get_poll_events->sock_reselect->sock_get_poll_events->... would be possible.
2. IMO, the code snippet
if (event & POLLIN) { char dummy; /* Linux 2.4 doesn't report POLLHUP if only one side of the socket * has been closed, so we need to check for it explicitly here */ if (!recv( sock->obj.fd, &dummy, 1, MSG_PEEK )) event = POLLHUP; } [...]
if (event & (POLLERR|POLLHUP)) set_select_events( &sock->obj, -1 );
is wrong, because an empty read only signals that the upstream connection was closed. The downstream connection may still be open, i.e. FD_WRITE events may well occur. In this case it seems to be wrong to do set_select_events( &sock->obj, -1 ) _unless_ the kernel had signalled POLLHUP|POLLIN, which means that both sides of the socket have been closed. Thus, if we have an empty read but no POLLHUP from the kernel, we should signal FD_CLOSE to the app, but not pretend we had got POLLHUP as the current code does.
Right?
Martin