[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Threads and asyncs
From: |
NIIBE Yutaka |
Subject: |
Re: Threads and asyncs |
Date: |
Wed, 4 Sep 2002 09:28:45 +0900 (JST) |
In threaded applications, we should avoid "asynchronous" signal
handling. This is some sort of common technique/discipline, I think.
If we do want asynchronous signal handling in threaded applications,
we'll open can of dead-lock worms. Signal handler will access some
shared data to affect some thread control, which means, need some
mutual exclusion for that. What if when signal hander will be invoked
asynchronously in the critical region? Signal handler cannot get the
lock. That'll be cause of the dead lock(s).
(Usually) In threaded applications, signal is handled synchronously,
by assigning a dedicated thread for signal handling. I mean, a thread
like that:
while (1)
{
switch (get_signal ()) /* Blocked if none */
{
case SIGINT:
sigint_handler ();
break;
case SIGHUP:
sighup_handler ();
break;
/* ... */
}
}
--
- Re: Threads and asyncs, (continued)
- Re: Threads and asyncs, Thomas Bushnell, BSG, 2002/09/04
- Re: Threads and asyncs, Tom Lord, 2002/09/04
- Re: Threads and asyncs, Lynn Winebarger, 2002/09/04
- Re: Threads and asyncs, Tom Lord, 2002/09/04
- Re: Threads and asyncs, Thomas Bushnell, BSG, 2002/09/04
- Re: Threads and asyncs, Tom Lord, 2002/09/04
- Re: Threads and asyncs, Lynn Winebarger, 2002/09/05
- RnRS process/history/documentation (was Re: Threads and asyncs), Lynn Winebarger, 2002/09/02
- Re: Threads and asyncs, Thomas Bushnell, BSG, 2002/09/02
- Re: Threads and asyncs, Marius Vollmer, 2002/09/03
- Re: Threads and asyncs,
NIIBE Yutaka <=