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? thanks, Pádraig. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
