[Lazarus] Finding out how a program's being terminated
Mark Morgan Lloyd
markMLl.lazarus at telemetry.co.uk
Sat Feb 16 13:24:19 CET 2013
Sven Barth wrote:
>>> An important note about signal handlers: don't do anything complicated
>>> in them. Maybe just set a flag (e.g. "SignalTerminated := True") and
>>> handle that in your application loop once control returned. Signals
>>> are executed from a different stack space and a different context and
>>> thus showing e.g. dialogs from within the handler is a bad idea(TM).
>>
>> Yes, agreed. Is an Application.QueueAsyncCall() safe?
>
> It could be that this also allocates memory to append the queued call,
> so this might also be probematic...
Thanks, noted.
>>> The reason for this "first TERM then KILL" approach is that an
>>> application could either hang (and thus not respond correctly to TERM
>>> if it has hooked it) or it could just ignore the TERM. So on shutdown
>>> the init system normally sends a TERM to all processes first and gives
>>> them a chance to cleanup any data they might want to save and then
>>> those applications that are left are killed.
>>
>> Yes, but I also found it /explicitly/ in a script (Slackware rc6.d or
>> somesuch).
>>
>
> If I'd need to guess than I'd say that this is the script executed by
> Slackware's init process if run level is 6.
Yes, but I'm making the point that at least on that system it's not
something implicit to init. Debian looks like it does it differently,
but I'd imagine that the end result is pretty much the same.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
More information about the Lazarus
mailing list