On Wed, Jul 21, 2004 at 04:57:55PM +0200, Marco Gerards wrote: > Marcus Brinkmann <[EMAIL PROTECTED]> writes: > > volatile sig_atomic_t should_we_die; > > global flag every second should be ok. A max delay of 1 second at kill is > > acceptable, IMHO. > > Absolutely. AFAIK signals are not reliable anyway.
I have a problem with this: doing a check every second means the program will run every second. This means that, even if nothing at all happens to the program, the process wil not be swapped out. This isn't an issue for most systems, but I think it still should be avoided if possible. Can't one thread just do something like this: while (1) { pause (); <handle signal on the basis of variables set by the signal handler here> } Of course this may have a problem if a signal arrives before the pause () is called. For that the solution below can be used, although in this case (every handled signal means the program should exit) it isn't really an issue, because it only happens at startup. At startup signals aren't reliable anyway, because the handlers may not have been set yet. What you could also do is open a pipe, and select () on it with infinite timeout, and have the signal handler write to it. If that gives a race condition (because the thread listening to the pipe is running while the signal handler is not yet done, I don't know if that is possible), you can poll a variable (as suggested above) only after there has been data through the pipe, until the signal has been handled. I don't like polling, and think it should be avoided whenever possible (except if very much data is expected, so almost every poll returns data.) Thanks, Bas -- I encourage sending me encrypted e-mail. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. for more information, see http://129.125.47.90/e-mail.html
pgph1nXnyZjzG.pgp
Description: PGP signature
_______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-hurd