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