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

[Mark Morgan Lloyd]

Ludo Brands wrote:
> 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.

But as I've said to Sven, in my case I'm specifically interested in the 
single-user case and it will take a user a finite time to move between 
dialogue boxes (which is probably a good argument for instead using 
modal forms instead of dialogue boxes in this role, and to make sure 
they're spread over the screen).

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

Agreed. Any shared part should only be written during the start of the 
program run, never in response to a signal or shutdown event.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]