On Wednesday 02 April 2008, Pádraig Brady wrote: > Mike Frysinger wrote: > > On Tuesday 01 April 2008, Pádraig Brady wrote: > >> + /* Setup handlers before fork() so that we > >> + * handle any signals caused by child, without races. */ > >> + signal (SIGALRM, cleanup); /* our timeout. */ > >> + signal (SIGINT, cleanup); /* Ctrl-C at terminal for example. */ > >> + signal (SIGQUIT, cleanup); /* Ctrl-\ at terminal for example. */ > >> + signal (SIGTERM, cleanup); /* if we're killed, stop monitored > >> process. */ + signal (SIGHUP, cleanup); /* terminal closed for > >> example. */ + signal (SIGTTIN, SIG_IGN); /* don't sTop if > >> background child needs tty. */ + signal (SIGTTOU, SIG_IGN); /* > >> don't sTop if background child needs tty. */ > > > > if you're using signal(), you have race problems. why not use > > sigaction() and friends instead ? > > I originally wrote this for util-linux-ng. > BSD and linux at least handle signal() sanely > so I wrote it for those. > > Since coreutils needs to be more portable, > I'll change to the more complicated sigaction instead. > > To be sure, are you referring to races where a signal > can be received while in the signal handler on some systems? > > Also there is the issue of restarting system calls > after the signal handler has run. > > Also there is the issue of resetting the signal > handler after it has run. > > Are there systems that coreutils supports currently > that doesn't follow BSD/linux semantics wrt the above 3 points?
afaik, Linux behaves as POSIX dictates. that means it does not behave as you describe above. newer versions of glibc may block the same signal from re-occuring, but it doesnt block other signals. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
