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