Re: select() hanging after terminal killed

["Matthias Andree" <matthias dot andree at gmx dot 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