[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: console-client signal handling

From: Bas Wijnen
Subject: Re: console-client signal handling
Date: Wed, 21 Jul 2004 17:26:28 +0200
User-agent: Mutt/1.3.28i

On Wed, Jul 21, 2004 at 04:57:55PM +0200, Marco Gerards wrote:
> Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum.de> 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.)


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

Attachment: pgpjZGvfhvrn0.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]