Accessing thread-specific storage within signal handlers

Accessing thread-specific storage within signal handlers

Post by Douglas C. Schmi » Wed, 16 Jun 1999 04:00:00



Hi,

        On page 169-171 of the book "Programming with Threads" by
Kleiman, Shah, and Smaalders there's a discussion of how to program
thread-specific signal handlers.  The example uses
pthread_setspecific() and pthread_getspecific() from within a signal
handler.  However, just 4 pages earlier, on page 169, the authors list
the POSIX async-safe functions, which do not include any of the
pthread_* functions.  Therefore, is it correct to assume that the
example of thread-specific signal handlers described a couple of pages
later is non-portable?  Note that the signal used in the example is
SIGFPE, which is a synchronous signal -- though the authors don't
explicitly state that their solution is limited to synchronous
signals.

        Thanks,

                Doug
--
Dr. Douglas C. Schmidt, Associate Professor
Department of Computer Science, Washington University
St. Louis, MO 63130. Work #: (314) 935-4215; FAX #: (314) 935-7302

 
 
 

Accessing thread-specific storage within signal handlers

Post by Tom Payn » Wed, 16 Jun 1999 04:00:00



:         On page 169-171 of the book "Programming with Threads" by
: Kleiman, Shah, and Smaalders there's a discussion of how to program
: thread-specific signal handlers.  The example uses
: pthread_setspecific() and pthread_getspecific() from within a signal
: handler.  However, just 4 pages earlier, on page 169, the authors list
: the POSIX async-safe functions, which do not include any of the
: pthread_* functions.  Therefore, is it correct to assume that the
: example of thread-specific signal handlers described a couple of pages
: later is non-portable?  Note that the signal used in the example is
: SIGFPE, which is a synchronous signal -- though the authors don't
: explicitly state that their solution is limited to synchronous
: signals.

I understand that, on many processors, SIGFPE is not synchronous.
AFIK, that's why the C Standard encourages longjmp'ing out of the
SIGFPE handler by specifying that return'ing from it invokes
"undefined behavior."  (But, per the C Standard, even reading a global
variable from a signal handler invokes "undefined behavior.")

Tom Payne

 
 
 

1. Thread-Specific Signal Received by Many Threads

Hi,

I am using Solaris's thr_kill to send a signal from thread A to
thread B. What I believe I have seen is that if I make thread A
relatively idle (in a loop waiting on a synchronization variable,
or calling sleep), then not only does thread B get the signal,
but apparently, so does thread A!

Can anyone shed any light on this strange behaviour?

Thanks,

Vaughan Jackson.

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

2. Character set questions

3. Using thread-specific storage

4. HELP:TI microLaser Plus

5. semaphore (sem_t) within signal (sigaction) handler

6. start up file

7. exception thrown from within a signal handler

8. Themes and Cascading Style Sheets, what's the difference?

9. Throwing an exception from within a signal handler

10. Thread Specific Storage

11. help with thread specific storage.

12. Thread specific storage