Re: Linux poll() <sigh> again

From: jimmy
Date: Fri May 12 2006 - 10:45:38 EST


Robert Hancock wrote:
linux-os (Dick Johnson) wrote:
POLLHUP means "The device has been disconnected." This would obviously
be appropriate for a device such as a serial line or TTY, etc. but for a
socket it is less obvious that this return value is appropriate.


Hardly "less obvious". SunOs has returned POLLHUP as has other
Unixes like Interactive, from which the software was ported. It
went from Interactive, to SunOs, to Linux. Linux was the first
OS that required the hack. This was reported several years ago
and I was simply excoriated for having the audacity to report
such a thing. So, I just implemented a hack. Now the hack is
biting me. It's about time for poll() to return the correct
stuff.

The standard doesn't require that a close on a socket should report POLLHUP. Thus this behavior may differ between UNIX implementations. If your software is requiring a POLLHUP to indicate the socket is closed I think it is being unnecessarily picky since read returning 0 universally indicates that the connection has been closed. Such are the compromises that are sometimes required to write portable software.


I have used the subsequent read() with a returned
value of zero, to indicate that the client disconnected
(as a work around). However, on recent versions of
Linux, this is not reliable and the read() may
wait forever instead of immediately returning.
If you want nonblocking behavior, you should set the socket to
nonblocking. This is a bit strange though, unless the data was stolen by
another thread or something. Are you sure you've seen this?

I don't use threads. The hang under the specified conditions was first
observed on 2.6.16.4 (that I'm running on this system). The hack, previously
used, i.e., the read of zero was used since 2.4.x with success except it's
a hack and shouldn't be required. It was not ever required on SunOs from
which the software was ported.

This may be a bug somewhere.. however, once again if you don't want read to block under any circumstances, set your sockets to non-blocking!

But that's another hack. AFAICS why ppl (mostly) use select/poll wud be to know if their send/recv/read/write would go thru rather than getting blocked!


-jb
--
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. - Albert Einstein
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/