Sven Barth wrote:
On 16.02.2013 09:22, Mark Morgan Lloyd wrote:
On unix (Linux, Solaris etc.) is it possible to determine how a program
written using Lazarus is being terminated? Specifically, is there any
different behaviour when a kill signal arrives from a routine term
signal, and is a title-bar close button simply a term signal?
SIGTERM can be caught and handled by application using a signal handler,
so it can do some cleanup or even ignore the signal completely.
SIGKILL can not be caught and will directly kill the process without any
chance for further progressing.
And a title bar close button does normally invoke a event of the used
GUI toolkit (in case of Windows it would be the message "WM_CLOSE", I
don't know the event names of GTK and Qt :) ) and not send a SIGTERM.
Thanks, I'll have a play with this later.
I'm trying to think ahead and plan for what a bunch of related (but not
necessarily tightly-coupled) programs do if there's e.g. a UPS shutdown
notification which sends a kill signal. Specifically, if there's a
routine term it is probably appropriate to save the current window
sizes etc. while if there's a kill because the UPS is trying to shut
everything down fast it's probably safest to assume that there's a risk
of multiple programs trying to access common files simultaneously.
If there is a SIGKILL you can't do anything in your program and you
won't be notified that you even got that signal.
OK, so a hypothetical program with term hooked makes sure it behaves
like a window manager close. If multiple related programs are shut down
manually by the user (WM or term signal) they can put up a dialogue
asking whether the state is to be saved, and it's reasonable (although
not strictly correct) to assume that the user won't OK all of these
simultaneously. Or if they are shut down by a kill signal they
presumably don't do OnCloseQuery (or whatever- working from memory) and
presumably don't run finalization blocks.
The thing that initially got me jittery was a shutdown script (from an
elderly Slackware) that first signalled term to everything, waited five
seconds and signalled kill. But if the term resulted in a dialogue
asking whether the state is to be saved then presumably the kill would
never OK this.
So I think this leaves two cautionary cases which arise because a term
signal can be sent to multiple programs simultaneously (e.g. by the
killall5 program). The first is that a shutdown caused by a term signal
should not attempt to e.g. save state to a .ini file if there's a risk
that that file is shared without waiting for manual confirmation. The
second is that if a shutdown presents a dialogue box this should not
have a user-friendly "I'll save your data after five seconds" default,
unless it's absolutely certain that the files won't be shared (this
might be acceptable for a WM close event, but definitely not for a signal).
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
