All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Hancock <hancockr@shaw.ca>
To: "linux-os (Dick Johnson)" <linux-os@analogic.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Linux poll() <sigh> again
Date: Fri, 12 May 2006 08:32:37 -0600	[thread overview]
Message-ID: <44649C85.5000704@shaw.ca> (raw)
In-Reply-To: <Pine.LNX.4.61.0605120745050.8670@chaos.analogic.com>

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!

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/


  reply	other threads:[~2006-05-12 14:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <6bkl7-56Y-11@gated-at.bofh.it>
2006-05-12  0:08 ` Linux poll() <sigh> again Robert Hancock
2006-05-12 11:53   ` linux-os (Dick Johnson)
2006-05-12 14:32     ` Robert Hancock [this message]
2006-05-12 14:46       ` jimmy
2006-05-12 14:57         ` linux-os (Dick Johnson)
2006-05-12 15:06           ` Eric Dumazet
2006-05-12 15:12           ` Davide Libenzi
2006-05-12 18:49         ` David Schwartz
2006-05-11 14:25 linux-os (Dick Johnson)
2006-05-11 20:47 ` Nishanth Aravamudan
2006-05-11 21:04   ` linux-os (Dick Johnson)
2006-05-11 21:16     ` Nishanth Aravamudan
2006-05-12 11:42       ` linux-os (Dick Johnson)
2006-05-12 10:37     ` Jan Engelhardt
2006-05-12  5:26 ` David Schwartz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44649C85.5000704@shaw.ca \
    --to=hancockr@shaw.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-os@analogic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.