[Top][All Lists]

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

Re: console-client signal handling

From: Marcus Brinkmann
Subject: Re: console-client signal handling
Date: Thu, 22 Jul 2004 01:34:56 +0200
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Wed, 21 Jul 2004 17:26:28 +0200,
Bas Wijnen wrote:
> 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.

Good point.
> 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.

No, the signal handlers can be setup before a cleanup is necessary,
and before they are setup they are set to the default handler, which
will usually kill the program (without cleanup, but as I said it's
before cleanup is necessary, so this is what you want).

We could ignore the race.  It's small and nothing depends on it (any
script that tries to kill the client must check and retry the kill
anyway, in case of bugs that prevent it from going away).

Or, we could just use sigsuspend.  I didn't even know it exists, but
it's in the glibc manual and seems to fit our needs.

> 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.

Nice trick.  Would work, too, although it has some overhead (not that
performance matters here, but you'd not really want to need this for
this simple problem).
> 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.)

Well, I agree.  I just was ignorant of alternatives, didn't even know


reply via email to

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