Re: Linux poll() <sigh> again

[jimmy]

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/