Quit on child exit rather than pty EOF

[GoogleCodeExporter]

The following commands will cause an xterm (or any other terminal emulator) to 
exit immediately.

    # For exposition's sake: huponexit is off by default
    shopt -u huponexit
    sleep 30&
    exit

mintty, on the other hand, will stick around until the sleep exits. huponexit 
will cause mintty to close immediately, but it will also kill the sleep 
command. mintty acted the way xterm does until 0.9.5. The following simple 
patch restores the 0.9.4 exit behavior.  This patch does not affect --hold, 
which operates as it did before.

Index: child.c
===================================================================
--- child.c (revision 1253)
+++ child.c (working copy)
@@ -206,7 +206,8 @@
     FD_SET(win_fd, &fds);  
     if (pty_fd >= 0)
       FD_SET(pty_fd, &fds);
-    else if (pid) {
+
+    if (pid) {
       int status;
       if (waitpid(pid, &status, WNOHANG) == pid) {
         pid = 0;
@@ -245,7 +246,8 @@
         if (s)
           term_write(s, l);
       }
-      else // Pty gone, but process still there: keep checking
+
+      if (pid != 0 && pty_fd < 0) // Pty gone, but process still there: keep 
checking
         timeout_p = &timeout;
     }

Original issue reported on code.google.com by dan.cola...@gmail.com on 6 Feb 2012 at 5:01

[GoogleCodeExporter]

There is also this effect:
Within mintty, start another:
mintty &
Then try to close the first - it won't but hang around until all child 
terminals are closed.

(I had not reported this earlier because I was afraid a fix might affect the 
application-controlled HUP interaction that I desired :).

I confirm this patch also fixes the close-blocking by a spawned terminal and 
does not affect HUP control by embedded applications (like mintty -e mined....).

Original comment by towom...@googlemail.com on 20 Feb 2012 at 1:17

[GoogleCodeExporter]

Mintty quits on pty EOF (modulo the --hold setting), which is a deliberate and 
I think valid design decision, so I don't accept that this is a defect. 
Arguably it makes more sense than quitting on child process exit, because other 
processes still connected to the pty might still want to write to it. The 
Windows console window and hence the Cygwin console behave likewise. Ssh 
sessions also finish on pty EOF rather than child exit.

If you don't want a process to hold up mintty quitting, you can invoke it 
through the 'setsid' utility from the util-linux package to put it into its own 
session. Also, you can of course quit mintty with the close button or Alt+F4 
shortcut.

Having said all that, you are of course right that xterm and other X terminal 
emulators quit on child exit, and that mintty used to behave the same way. 
Apparently it would save a few complaints if that was reinstated.

The trigger for the design change was issue 215: mintty was occasionally left 
open because the SIGCHLD signal wasn't always being delivered, and that 
appeared to be connected to mintty's use of the /dev/windows device.

At the time, I did consider what you're suggesting with the patch here, but 
decided against it because it means polling the global process table with 
waitpid() after every bit of output and every Windows event, and I was wary 
about the impact that might have.

I'll need to investigate whether the issue with the unreliable SIGCHLD is still 
there after the changes in Cygwin 1.7.10, and produce a small test case to take 
to the Cygwin list if it is (which of course I should have done before). Don't 
let me stop you if you want to have a go at this.

Original comment by andy.koppe on 8 May 2012 at 5:07

• Changed title: Quit on child exit rather than pty EOF
• Changed state: Accepted
• Added labels: Type-Enhancement, Priority-Medium, Difficulty-Medium
• Removed labels: Type-Defect

[GoogleCodeExporter]

Mintty's current behavior irks me to the point of building and running a 
patched mintty all the time. Maybe it's long experience, but the traditional 
xterm behavior feels right to me because it gives me more explicit control over 
when a session ends.

I've been using this patch for months with no ill effects and no noticeable 
performance problems. The process table is small and polling it isn't a problem 
in practice, even with quite a few mintty instances. I also haven't noticed any 
SIGCHLD losses in any program I've used.

Original comment by dan.cola...@gmail.com on 8 May 2012 at 8:18

[GoogleCodeExporter]

If A forks B, the discussion considers how A or its parent terminal might 
behave when A is asked to close.

On the other hand, if B is a terminal, one could arguably expect it to detach 
itself from the controlling tty, because there is no logical relation between 
them (except maybe for debugging output...)
I think I remember a discussion claiming this long ago...
So I checked the sources and xterm does indeed have some calls to setsid but 
only under obscure #ifdefs, and in fact, on cygwin or SunOS it does not detach 
from the tty. Mintty also has a setsid call but that seems to be used for 
something else.

So my suggestion for mintty (and terminals in general) would be to detach 
itself when started (similar to "daemonizing").

Original comment by towom...@googlemail.com on 23 May 2012 at 11:30

[GoogleCodeExporter]

Thomas, I think mintty's own behaviour with regards to its parent process is a 
related but separate issue.

Dan, the missing SIGCHLDs causing issue 215 appeared to be specifc to using 
select() on /dev/windows, so indeed I wouldn't expect them with the polling 
approach.

Original comment by andy.koppe on 29 May 2012 at 11:46