Sven Barth wrote:
On 16.02.2013 10:54, Mark Morgan Lloyd wrote:
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.
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?
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.
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).
Windows does a similar thing by the way. On shutdown (or logoff) all
applications are notified that the user session terminates and are given
a chance to cleanup. Then the "application does not respond" dialog is
shown (in versions pre Vista a dialog with a "count down progress bar"
is shown in versions from Vista on a "these applications hinder
shutdown/logoff" overlay is shown). If the applications did not
terminate till then each remaining application is killed using
ProcessTerminate which can not be caught by the application either.
I've found Windows' UPS API to be the most reliable way of shutting apps
down fast when rebooting a system is more important than having each
program do its housekeeping.
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).
This is why I linked the "asking for a security hole" blog entry in the
other thread. World writable files are simply not good. You get only
problems with them.
I agree, but there's a big difference between "world" and "multiple
programs running in the context of the same user".
--
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
