On 16.02.2013 11:46, Mark Morgan Lloyd wrote:
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?
It could be that this also allocates memory to append the queued call,
so this might also be probematic...
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).
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.
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.
If shutting down is more important than house keeping on a Unix system
than you just need to send a SIGKILL to each process and then initiate
shutdown.
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".
I consider this the same, because you can't guarantee the write order of
the programs and AFAIK TIniFile writes the complete file and not only a
part of it.
Regards,
Sven
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
