On Tue, 14 Mar 2000, Ove Kaaven wrote:
> On Mon, 13 Mar 2000, Matthew Cline wrote:
> > The reason for the select being aborted is that the poll()
> > reports the socket as being POLLHUP.
> >
> > I really have no clue as to what might be wrong, or how to track
> > down the problem. Any help would be appreciated.
>
> I would like concise documentation for poll() myself, but from what
> I've been able to dig up, POLLHUP and POLLERR are nonmaskable and
> appears to be fatal. POLLHUP probably has something to do with the
> socket being closed or shut down (although I'm not sure from which
> side) so that it can no longer be written to, but any remaining
> data can still be read from it.
POLLHUP on a TCP socket (which is what my problem socket is)
means that the receiving part of the socket has been shutdown.
I've looked into it some more, and it doesn't look like the
problem is that the socket is being polled repeatedly after
POLLHUP has been set; it's not locking up the wineserver or
anything. As far as I can tell, the problem is that the socket
is being shutdown even though nothing should be causing it to
shutdown: the socket is created, an fcntl() is done to make it
non-blocking, it's polled, and all of the sudden it has POLLHUP
set; I've made sure of this by tracing all of the system calls
with "strace", and that's really all that's happening to the
socket. The application probably doesn't have any code to deal
with the situation of a newly created TCP socket that's already
been shutdown, so the situation confuses it.
I've poked around in the kernel code a little to try and figure
out what might cause this behavior, but it's beyond me. I
tried to set SO_DEBUG with setsockopt(), but it turns out that
the Linux kernel doesn't produce much (or any) output with this
set on. So I'm still clueless as to what the ultimate cause of
the problem is.
--
Matthew Cline | Suppose you were an idiot. And suppose that
[EMAIL PROTECTED] | you were a member of Congress. But I repeat
| myself. -- Mark Twain
