delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2010/03/05/06:02:40

X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Message-ID: <4B90E4BC.5050808@towo.net>
Date: Fri, 05 Mar 2010 12:02:20 +0100
From: Thomas Wolff <towo AT towo DOT net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: terminals getting killed on parent's termination
References: <201002261446 DOT o1QEki2k024924 AT mail DOT bln1 DOT bf DOT nsn-intra DOT net> <416096c61002261229j31f92387u8b8e3e9b716cb131 AT mail DOT gmail DOT com> <4B8BEACA DOT 4010003 AT towo DOT net> <416096c61003032349h6f22d223v7aa03c07f4f27475 AT mail DOT gmail DOT com>
In-Reply-To: <416096c61003032349h6f22d223v7aa03c07f4f27475@mail.gmail.com>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On 04.03.2010 08:49, Andy Koppe wrote:
> Thomas Wolff:
>    
>> Andy Koppe:
>>      
>>> Mintty has default handling for SIGHUP, i.e. it exits.
>>>        
>> Actually (another topic but related) mintty has a great feature here: it
>> passed the SIGHUP to its client application and if that application catches
>> and handles the SIGHUP, mintty does *not* exit.
>>      
> I don't think that's true. See signal_thread() in child.c: if mintty
> receives a SIGINT, SIGTERM, or SIGHUP, it sends a SIGHUP to the child
> process to say that the terminal is disappearing and then exits
> immediately.
>
> (I'm not convinced that sending the SIGHUP manually should be
> necessary actually, i.e. I'd have expected SIGHUP to automatically be
> sent to attached processes when the master side of the pty is closed
> due to mintty exiting. But I haven't got 'round to look into this
> properly.)
>
>
>    
>> This enables an application
>> to be embedded into mintty as a terminal container and implement some
>> reasonable "Really exit?" behaviour with the option not to exit.
>> I suspect though, that this feature might not be on purpose since the
>> semantics of SIGHUP would be slightly tweaked here. Anyway, it's very
>> useful, so I'd like to ask to please make it a defined feature to rely on
>>      
> This conflicts with your request for mintty to ignore SIGHUP.
>    
Actually there are two different scenarios here which I didn't describe 
clearly:

1. Termination of a terminal's parent. This should not abort the 
terminal session, whether or not the notification mechanism is HUP. (In 
the case console -> xterm you said it's due to console attachment, 
whatever that means in detail.)

2. Manual termination of a terminal with a window manager operation 
(like clicking the Close X button, selecting Close from the menu, 
pressing Alt-F4).
In the case of a Windows application, this is a WM_CLOSE message being 
handled (not a HUP as I had assumed).
If the direct child process of the terminal explicitly catches HUP, the 
terminal should not terminate. It should just send HUP to its child and 
then terminate only if the child terminates (overriding a "hold after 
command terminates" option in this case, so the option can be reset when 
handling this).
This works fine with xterm.
It also works with mintty but only once, due to the 'killed' flag in the 
function child_kill in child.c.
Should I propose a patch?

Thomas

--
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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019