select() hanging after terminal killed

Thomas Wolff
Thu May 26 22:44:00 GMT 2011

On 29.04.2010 17:21, Christopher Faylor wrote:
> On Thu, Apr 29, 2010 at 05:11:00PM +0200, Corinna Vinschen wrote:
>> On Apr 29 12:53, Thomas Wolff wrote:
>>> If a terminal gets killed, its tty/pty is not properly closed.
>>> This is likely to confuse applications and let them hang, as observed
>>> with mined (thanks Andy for the report) and joe.
>>> On Linux and SunOS, a subsequent read() return 0 (indicating EOF);
>>> any further read() returns -1, errno indicating EIO.
>>> Immediate write() may report success a few times,
>>> further write() returns -1, errno indicating EIO.
>>> On Linux, select() indicates an exception and EIO.
>>> On SunOS, select() indicates both an exception and input (weird),
>>> and ENOENT initially, EIO on further attempts.
>>> 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.
>> Can you create a simple testcase?
I finally managed it... (attached).
In a mintty or xterm, run hupsel > /dev/tty... (some other terminal to 
Then close the terminal (click on 'X' corner).
On Linux, the program terminates.
On cygwin, the program hangs in select().

> Hmm.  Since the owner has both sides of the pipe open maybe closing the
> slave side doesn't trigger select.
> It's possible that Corinna's changes to tty handling might make this
> work better.  It would be interesting to see how this works in a recent
> snapshot.
Unfortunately not.

Kind regards,
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: hupsel.c
URL: <>
-------------- next part --------------
Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list