Set thread-local sig_atomic_t in signal handler?

Ian Pilcher
Thu Sep 26 15:34:00 GMT 2013

Short version:

Can I use a thread-local sig_atomic_t in a signal handler?  I.e.:

  static __thread volatile sig_atomic_t exit_flag = 0;

  static void handler(int signum __attribute__((unused)))
      exit_flag = 1;

(Signals will be sent to specific threads with pthread_kill.)

Long version:

I am working on a program to monitor various aspects of my NAS and
display them on the front-panel LCD.  The program is written in C,
targeting CentOS 6.4 (gcc 4.4.7, glibc 2.12).

The program is multi-threaded.  Several "monitor" threads do the work
of gathering and parsing information about the system -- each at an
interval appropriate for the type of information it is gathering -- and
the root thread cycles through the different status displays on the LCD
on its own schedule (currently changing the display every 3 seconds).

All of the threads spend most of their time sleeping.  Thus far I've
been using a pthread condition variable and pthread_cond_timedwait to
tell the monitor threads when it's time to shut down.

Now I'm trying to make the program a bit more resilient in the face of
a misbehaving child process.  (It uses programs like hddtemp, smartctl,
mdadm, etc., to gather certain information.)  If an external command
hangs, the thread that spawned it will currently just sit there waiting
to read from its end of the pipe.  I hope to use poll (or ppoll) to
time out and kill the child if no output ever shows up.

Using ppoll, however, means that I won't be able to use a condition
variable to wake up the monitor threads.  A signal, sent with
pthread_kill, would be ideal if the handler can set a thread-local flag.
(I can easily use ppoll as a substitute for nanosleep, where I'm
currently calling pthread_cond_timedwait.)

Will this work?


(BTW, I am aware of pthread_cancel, but it would be a huge job to
convert my code to the stack-based approach that it forces.)

Ian Pilcher                               
Sometimes there's nothing left to do but crash and burn...or die trying.

More information about the Gcc-help mailing list