This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: select() hanging after terminal killed

Thomas Wolff wrote on 2010-04-29:

On 29.04.2010 13:28, Matthias Andree wrote:
Am 29.04.2010 12:53, schrieb Thomas Wolff:

[on closed terminal]

On Linux, select() indicates an exception and EIO.
On SunOS, select() indicates both an exception and input (weird),

Not weird, you appear to be misunderstanding select().
An IEEE Std 1003.1 compliant select():

- only states that a subsequent read() will *not block*
this includes EOF and error, as they make read() return without blocking)

- makes *no statements about success*

Oh, right, so apparently Linux is wrong here (since it does not report read availability...).

Arguably yes, probably an omission in your system. (Note that older POSIX versions didn't specify that errors means readability).

Please look if a relevant bug is filed, and if not, please do so.

On Cygwin, the following is observed:
* EOF is not signalled on read(); rather EIO is indicated right away.
   (Maybe not too bad, an application can handle that as well.)
* select() with timeout hangs.

Especially the latter can hardly be handled by an application.

Pointers for workarounds: alarm(), signal().

So I could setup alarm() to get myself signal()ed while waiting in a long sleep().
But the granularity is in seconds only, so this is not a substitute for most use cases typically handled by calling select().
Thanks for the information anyway.

Rather than discussing the downsides, you might more efficiently just read the standard, or the system documentation, which would then point you to setitimer().

Matthias Andree

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]