Subj : pthread_getspecific or __thread for signal handler?
To   : comp.programming.threads
From : Ian Pilcher
Date : Mon Jan 31 2005 02:29 pm

I've been slowly grinding along on my pthread-safe alarm function (so I
can interrupt blocked stdio functions in a multi-threaded program).  My
design thus far has been to use a separate thread for each alarm object.
Such an "alarm thread" spends most of its time blocked in
pthread_cond_wait (waiting to be set) or pthread_cond_timedwait (when
"ticking").  When the alarm thread "rings", it sends a SIGALRM to its
"target thread" via pthread_kill.

So far so good, but since I have to use a process-wide signal handler
for SIGALRM, I need to determine whether or not the thread that got
the signal actually has an associated alarm.  If not, I pass the signal
on to whatever signal handler was installed before mine (saved in the
oldact from sigaction).

So my challenge is to access some sort of thread-local storage in a
signal handler.  The platform is Fedora Core 3, and there are already a
fair number of Linux-isms in the program, so uber-portability is not
going to happen anyway.

Both pthread_getspecific and __thread appear to be working.  My question
is which is the "safest" option.  The safest option being the one that
will break most obviously on a system where it doesn't work, rather than
lurking around until the program is run in a certain pathological
environment.

Opinions?

Thanks!

-- 
========================================================================
Ian Pilcher                                        i.pilcher@comcast.net
========================================================================

.