This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: terminals getting killed on parent's termination


Andy Koppe wrote:
Thomas Wolff:
In general, a GUI application started in the background, like a terminal,
should detach itself from its parent process so that it survives if the
parent is terminated.
Says who?
Common practice in Unix/Linux/X environments.
I've finally got round to trying to confirm this on Linux, and the
results make me wonder what exactly you are basing this assertion on.
Out of the terminals I tried, xterm and urxvt ignored SIGHUP, whereas
rxvt, konsole, gnome-terminal, and lxterminal terminated. Among a
bunch of other GUI apps, only gvim ignored SIGHUP, whereas firefox,
gimp, abiword, konqueror and others all terminated.
Thanks for this more extensive survey, comments below.

And user expectation that an
interactive session (which may e.g. contain an editing session with unsaved
changes...) should not be aborted by an unrelated event.
You do have a point there (which is why mintty has the warning when
it's closed with background processes running). Closing the terminal
that a program was started from is not a completely unrelated event,
though, and there might well be users that do expect everything to
quit in that case. In other words, you don't help your case by stating
opinion as fact and ignoring the other side of an argument.
Well, I didn't mean "should" as stating a fact but more as a request for discussion (contributors welcome).
(Maybe one *should* be aware that the usage of "SHOULD" in RFCs may have somewhat tweaked the perception of "should" in computing language,
or I might have added an IMHO attribute :-) )


Concerning
Closing the terminal that a program was started from is not a completely unrelated event,
this is also a matter of taste and use case but just using a command line to *start* an application does not indicate the intent that the command line should continue to *host* the application in the sense of a session.

My case is that sturdiness of an application against external impact is the more desirable the more interactive and potentially unsaved data it maintains.
This is not so much the case with browsers but at least firefox has introduced the feature of "Restore session" as a remedy in case it gets killed.
It is more the case for a shell session and even more for an editor.
Your survey above may also be interpreted this way: the most established terminals (xterm, rxvt-unicode) do maintain this stability, while some "newcomers" don't care (yet).
Among editors, apparently gvim supports my point, while emacs, gimp, abiword don't - but that can also just mean the issue has not received common awareness by now.


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).
Here we go again.

My little survey showed that xterm is the only terminal that does
things that way; all the others notify the child and quit immediately.
Maybe that's why xterm is still the mainstream terminal in the X world? (+ IMHO + ;-) )

It also works with mintty but only once, due to the 'killed' flag in the
function child_kill in child.c
Funnily enough, this was a deliberate design decision, i.e., a
compromise between the two approaches. Unlike rxvt et al., it does
allow an application to say bye and prompt about unsaved data. Yet
unlike with xterm, a misbehaving application won't stop the user from
closing the terminal, because guess who'd be blamed for that.
A well-considered approach; however, since mintty is the only terminal that applies this compromise, applications cannot assume this as a protocol, so I doubt there is much use case.
Actually I noticed xterm also implements a useful compromise: With a window manager close event (Click "X", Alt-F4) it behaves as I had described, with "Quit" from its own menu, on the other hand, it always quits, thus avoiding the problem of an "unkillable" terminal.


Finally, let me discuss again my use case of embedding an application into a terminal ("container" model): the "HUP-delegate" protocol that I favour would enable a text-based command-line application to raise itself to a desktop application, including the option of implementing any application-specific "Really exit?" or "Save first?" behaviour. This would be another great feature of the terminal.
So please consider again these two options:
* Follow xterm like this: Apply "HUP-delegate" (i.e. forward HUP, leave quit decision to application) to the top-right Close button ("X"), and quit on Close from the menu; (Alt-F4 is not a big issue since it's remappable already.)
* Offer an option to apply "HUP-delegate" to "Close".


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]