#### 25.7.7 Remembering a Signal to Act On Later ¶

Instead of blocking a signal using the library facilities, you can get almost the same results by making the handler set a flag to be tested later, when you “unblock”. Here is an example:

    /* If this flag is nonzero, don’t handle the signal right away. */
    volatile sig_atomic_t signal_pending;

    /* This is nonzero if a signal arrived and was not handled. */
    volatile sig_atomic_t defer_signal;

    void
    handler (int signum)
    {
      if (defer_signal)
        signal_pending = signum;
      else
        ... /* “Really” handle the signal. */
    }

    ...

    void
    update_mumble (int frob)
    {
      /* Prevent signals from having immediate effect. */
      defer_signal++;
      /* Now update mumble, without worrying about interruption. */
      mumble.a = 1;
      mumble.b = hack ();
      mumble.c = frob;
      /* We have updated mumble.  Handle any signal that came in. */
      defer_signal--;
      if (defer_signal == 0 && signal_pending != 0)
        raise (signal_pending);
    }

Note how the particular signal that arrives is stored in `signal_pending`. That way, we can handle several types of inconvenient signals with the same mechanism.

We increment and decrement `defer_signal` so that nested critical sections will work properly; thus, if `update_mumble` were called with `signal_pending` already nonzero, signals would be deferred not only within `update_mumble`, but also within the caller. This is also why we do not check `signal_pending` if `defer_signal` is still nonzero.

The incrementing and decrementing of `defer_signal` each require more than one instruction; it is possible for a signal to happen in the middle. But that does not cause any problem. If the signal happens early enough to see the value from before the increment or decrement, that is equivalent to a signal which came before the beginning of the increment or decrement, which is a case that works properly.

It is absolutely vital to decrement `defer_signal` before testing `signal_pending`, because this avoids a subtle bug. If we did these things in the other order, like this,

      if (defer_signal == 1 && signal_pending != 0)
        raise (signal_pending);
      defer_signal--;

then a signal arriving in between the `if` statement and the decrement would be effectively “lost” for an indefinite amount of time. The handler would merely set `defer_signal`, but the program having already tested this variable, it would not test the variable again.

Bugs like these are called timing errors. They are especially bad because they happen only rarely and are nearly impossible to reproduce. You can’t expect to find them with a debugger as you would find a reproducible bug. So it is worth being especially careful to avoid them.

(You would not be tempted to write the code in this order, given the use of `defer_signal` as a counter which must be tested along with `signal_pending`. After all, testing for zero is cleaner than testing for one. But if you did not use `defer_signal` as a counter, and gave it values of zero and one only, then either order might seem equally simple. This is a further advantage of using a counter for `defer_signal`: it will reduce the chance you will write the code in the wrong order and create a subtle bug.)