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]
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
