Set thread-local sig_atomic_t in signal handler?

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

 



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?

Thanks!

(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                                         arequipeno@xxxxxxxxx
Sometimes there's nothing left to do but crash and burn...or die trying.
========================================================================




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux