[Lazarus] Finding out how a program's being terminated

[Ludo Brands]

On 02/16/2013 10:54 AM, Mark Morgan Lloyd wrote:
> 
> 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.
> 
I wouldn't count on that. See below.

> 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.
> 
That is afaik still the default behaviour of init. You have 5 secs
between SIGTERM and SIGKILL. Are all users going to click OK in 5 secs?
Also watch out that a signal handler runs asynchronously. You aren't
allowed to do a lot in a signal handler and should not use non-reentrant
functions such as malloc. Pop ups in signal handlers are not a good idea.

> 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).
> 
What about splitting configuration in a global read-only part and a
local read-write session part? As mentioned before INI files are no good
for shared read/write configuration saving.

Ludo