Re: select() hanging after terminal killed

["Matthias Andree" <matthias.andree@gmx.de>]

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:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple