Re: Linux poll() <sigh> again

[linux-os (Dick Johnson)]

On Fri, 12 May 2006, jimmy wrote:

> 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.

This is from the Linux man-page shipped with recent distributions


SOCKET(7)                  Linux ProgrammerâEUR(tm)s Manual                 SOCKET(7)



        +--------------------------------------------------------------------+
        |                            I/O events                              |
        +-----------+-----------+--------------------------------------------+
        |Event      | Poll flag | Occurrence                                 |
        +-----------+-----------+--------------------------------------------+
        |Read       | POLLIN    | New data arrived.                          |
        +-----------+-----------+--------------------------------------------+
        |Read       | POLLIN    | A connection setup has been completed (for |
        |           |           | connection-oriented sockets)               |
        +-----------+-----------+--------------------------------------------+
        |Read       | POLLHUP   | A disconnection request has been initiated |
        |           |           | by the other end.                          |
        +-----------+-----------+--------------------------------------------+
        |Read       | POLLHUP   | A connection is broken (only  for  connec- |
        |           |           | tion-oriented protocols).  When the socket |
        |           |           | is written SIGPIPE is also sent.           |
        +-----------+-----------+--------------------------------------------+
        |Write      | POLLOUT   | Socket has enough send  buffer  space  for |
        |           |           | writing new data.                          |
        +-----------+-----------+--------------------------------------------+
        |Read/Write | POLLIN|   | An outgoing connect(2) finished.           |
        |           | POLLOUT   |                                            |
        +-----------+-----------+--------------------------------------------+
        |Read/Write | POLLERR   | An asynchronous error occurred.            |
        +-----------+-----------+--------------------------------------------+
        |Read/Write | POLLHUP   | The other end has shut down one direction. |
        +-----------+-----------+--------------------------------------------+
        |Exception  | POLLPRI   | Urgent data arrived.  SIGURG is sent then. |
        +-----------+-----------+--------------------------------------------+


If linux doesn't support POLLHUP, then it shouldn't be documented.
I got the same king of crap^M^M^M^Mresponse the last time I reported
this __very__ __obvious__ defect!  The information is available
in the kernel. It should certainly report it, just like other
operating systems do, including <shudder> wsock32.

>>
>>>
>>>>> 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!
>

Yes. You need to know if something has changed. This could mean
many things such as new data available or a disconnection. This
is a communications link for crysake, one needs to handle
communications events.

>
> -jb
> --
> Only two things are infinite, the universe and human stupidity, and I'm
> not sure about the former. - Albert Einstein
>

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips).
New book: http://www.lymanschool.com
_


****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@xxxxxxxxxxxx - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.
-
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/