On Fri, Aug 19, 2011 at 05:17:52PM +0200, Harald Becker wrote: > Hallo Rich! > > > sigfillset(&set); > > sigprocmask(SIG_BLOCK, &set, 0); > > sigemptyset(&set); > > sigaddset(&set, SIGTERM); /* and any others I want to handle */ > > sigprocmask(SIG_UNBLOCK, &set, 0); > > > > This is a lot more robust. > > Robust yes ... such robust that it disables also fatal signals which may > lead to disastrous results, as such situations will no more terminate > the process and may continue running into possibly indeterminable > states!! ... think of illegal instruction traps and others.
Illegal instruction trap cannot happen unless you've written nonsense code that clobbers function pointers or such, in which case whatever undefined action happens when SIGILL is blocked is no worse than the nonsense code you already wrongly executed. > I do not want to participate in the hollow war here, but the code > fragment above is one of those I really hate. I even had to live with > watching on how people got wounded because of such a disastrous > situation originating in a colleges comparable programming :-( This type of code is necessary defensive programming to protect oneself against system-specific signals (e.g. SIGPWR) with default action that terminates the program. You could of course poll them with sigwaitinfo (e.g. in a dedicated thread) and terminate cleanly on any unknown signal, which would be a lot better than terminating by the default action and leaving all your data in a corrupt state. Rich _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
