Question on Signal delivery
Lee Jung Wooc
I'm programming some sever program that uses pthread interface.
I have wrote a wrapper and so far, it was fine.
Lately I have added some external monitoring facility using signal.
when the signal was shot(SIGUSR2) to program using kill command, like
$kill -USR2 2560
The program responds by writing on some designated pipe(fifo) which is
monitored by a simple program, like
p = fopen("./msgpipe","rw"); // prevents complex blocking and SIGPIPE...
etc.
while(true) {
fread(p,buff,count);
fwrite(stdout,buff,count);
}
At first the signal is delivered to main thread which is waiting for socket
connection,
But once one connection is established and another thread is created to
handle I/O
on connected socket, the signal generated by kill command is delivered to
the second
thread. And the thread which receives signal is, i guess, the last thread
created.
This situation induces problem while controlling the server.
So, I have tried to redirect signal to the main thread as follows.
void Server::SigProc(int signal) { // is static member
logf("sig %d handled in thread context %d\n",(int)getselfcurrent());
if ((int)getselfcurrent() != thrid_at_start) {
logf("redirecting...\n");
pthread_kill((pthread_t)thrid_at_start,signal)
return ;
}
logf("begin processing external control\n");
... rest of signal handling ...
return ;
}
After modifying like this, output was like :
$ kill -USR2 7777
sig 31 handled in thread context 1000
redirecting...
$ kill -USR2 7777
sig 31 handled in thread context -1000
begin processing external control
...
$
Looking at the result, I guessed :
* first signal was delivered to child thread.
* pthread_kill didn't worked
* second signal was delivered to correct thread
After watching the several times, I have found more
* thread that tried to redirect sinal was stuck
and was using cpu near 99 %
Any one please help to redirect signal to the mainthread or
any idea on how to make the signal to process is handled in
main thread context ?
Thanks a lot if somebody can help.
Lee Jung Wooc
Patrick TJ McPhee
Lee Jung Wooc <good...@comeng.ce.kyungpook.ac.kr> wrote:
% Any one please help to redirect signal to the mainthread or
% any idea on how to make the signal to process is handled in
% main thread context ?
You need to mask out the signal in all but the thread you want to
handle it. I think thread masks are inherited, so it should be enough
to mask it around the call to pthread_create(). You might think about
createing a separate thread whose job is simply to handle signals, start
it when the program starts, and then mask the signal in the main thread
before it does anything else.
--
Patrick TJ McPhee
East York Canada
pt...@interlog.com
Dave Butenhof
> Any one please help to redirect signal to the mainthread or
> any idea on how to make the signal to process is handled in
> main thread context ?
As Patrick McPhee has already suggested, I recommend that you stop relying on
a signal handler for this. To expand a little on his advice, begin by masking
SIGUSR2 in main(), before creating any threads. Then create a special thread
that loops on the sigwait() function, waiting for occurrences of SIGUSR2. (If
the signal is not masked in ALL threads, then it may "slip through" somewhere
while the signal thread is not waiting in sigwait() -- for example, while it's
starting, or while it's responding to the previous SIGUSR2.)
Beware that there's very little you can do safely in a signal handler. The
addition of the POSIX thread standard actually INcreases the length of the
async-signal safe function list -- but it also makes violations of the list
far more serious, and much more likely to actually fail. You can write() to
your log pipe, for example, but you can't use printf().
And, (ah-hem), you also cannot use pthread_kill() from a signal handler. So
there's no portable way to "redirect" a signal as you desire. Use sigwait().
/---------------------------[ Dave Butenhof ]--------------------------\
| Compaq Computer Corporation bute...@zko.dec.com |
| 110 Spit Brook Rd ZKO2-3/Q18 http://members.aol.com/drbutenhof |
| Nashua NH 03062-2698 http://www.awl.com/cseng/titles/0-201-63392-2/ |
\-----------------[ Better Living Through Concurrency ]----------------/
Lee Jung Wooc
Dave Butenhof 이(가) <3662B6A8...@zko.dec.com> wrote :.
>Lee Jung Wooc wrote:
>
>> Any one please help to redirect signal to the mainthread or
>> any idea on how to make the signal to process is handled in
>> main thread context ?
>
>As Patrick McPhee has already suggested, I recommend that you stop relying
on
>a signal handler for this. To expand a little on his advice, begin by
masking
>SIGUSR2 in main(), before creating any threads. Then create a special
thread
>that loops on the sigwait() function, waiting for occurrences of SIGUSR2.
(If
>the signal is not masked in ALL threads, then it may "slip through"
somewhere
>while the signal thread is not waiting in sigwait() -- for example, while
it's
>starting, or while it's responding to the previous SIGUSR2.)
Because I couldn't insert code in main() in trivial way, I modified my
thread wrapper
class to block all signals before actual pthread_create() and unblocks only
SIGUSR1
(my wrapper uses SIGUSR1 on its own purpose)
just after pthread_create(). Now, Modules are quite well arranged and looks
fine
, at least textually regarding signals and signal is delivered to correct
context now.
I appreciate about the idea of masking the signal at main(). I understand
that's reasonable.
about looping on sigwait() :
my program's main thread(sorry if this word is not appropriate) loops on
inbound socket
connection wating and signal delivery also expected by syscall interruption.
Any advise
about this structure ?
>
>Beware that there's very little you can do safely in a signal handler. The
>addition of the POSIX thread standard actually INcreases the length of the
>async-signal safe function list -- but it also makes violations of the list
>far more serious, and much more likely to actually fail. You can write() to
>your log pipe, for example, but you can't use printf().
Yes, to keep aside from hazard of such fail, I'm trying to use functions in
minimal
way. And never used library functions like printf() :).
>And, (ah-hem), you also cannot use pthread_kill() from a signal handler. So
>there's no portable way to "redirect" a signal as you desire. Use
sigwait().
Now, reason for redirection is gone and consider my trial was brutal and
funny.
One last question :
but how can I use sigwait to redirect signal ?
Dave Butenhof
> Because I couldn't insert code in main() in trivial way, I modified my thread
> wrapper class to block all signals before actual pthread_create() and
> unblocks only SIGUSR1 (my wrapper uses SIGUSR1 on its own purpose) just after
> pthread_create(). Now, Modules are quite well arranged and looks fine, at
> least textually regarding signals and signal is delivered to correct context
> now. I appreciate about the idea of masking the signal at main(). I
> understand that's reasonable.
Sorry, but if you cannot control the signal state in main() then you cannot use
"per-process" (asynchronous) signals like SIGUSR1 in any reliable way. It just
can't be done. You cannot "redirect" signals to the main thread from a signal
handler, as I already said. And if you can't control the main thread signal
state, then you cannot use sigwait(), either. Correct and reliable operation of
sigwait requires that the signal(s) on which you're waiting be masked in
ALL threads. Otherwise it may be delivered to some other thread instead of the
sigwaiter. That's especially true while the sigwait thread is NOT waiting
(because it's working on a previous signal)... but, even worse, a correct and
conforming implementation of the standard might deliver the signal to some
other thread (that has the signal unmasked) even while a thread is waiting in
sigwait. (Digital UNIX deliberately "prefers" sigwait threads in delivering a
signal, but that's not required, or even suggested, by the standard.)
If you're masking the signals in your create wrapper, you're also not affecting
the signal mask of any threads that might be created by other code in the
process. You might have an "embedded application" where you can be reasonably
sure that's not happening; but you have to be really, really careful about such
assumptions. Especially in any case where you cannot easily control the code
running in main(), I have to assume that you're writing a shared library, or at
least some system with similar restrictions; and that means that the "process
environment" isn't within your control. Assumptions that you only need to worry
about "your threads" may cause you a lot of trouble. (For example, the main
program might be compiled using an automatic parallel decomposition compiler,
causing it to become multithreaded without reference to any specific threading
operations; or it might use a sort or math library that creates multiple
threads. THOSE threads are also eligible for signal delivery, unless they're
created with the signal masked.)
> about looping on sigwait() : my program's main thread (sorry if this word is
> not appropriate) loops on inbound socket connection wating and signal
> delivery also expected by syscall interruption. Any advise about this
> structure ?
Sometimes that sort of design is necessary -- but I'd avoid it if at all
possible. Signals are simply too awkward. Adding threads makes the basic
limitations of the UNIX signal model far more obvious (and dangerous) than in a
"traditional" UNIX process.
> >And, (ah-hem), you also cannot use pthread_kill() from a signal handler. So
> >there's no portable way to "redirect" a signal as you desire. Use sigwait().
>
> Now, reason for redirection is gone and consider my trial was brutal and
> funny. One last question : but how can I use sigwait to redirect signal ?
You cannot use sigwait() to "redirect" a signal. It allows you to handle the
signal in clean, synchronous code, rather than dealing with the complications
of asynchronous per-process signals in a threaded process. Your big problem is
that you're apparently depending on the signal to interrupt your main thread's
socket read(). You could do that, (although there are some potential
complications), by having your separate sigwait thread use pthread_kill() to
interrupt the main thread. Remember that on return from sigwait, you're running
in a normal thread context, and you can use any POSIX function; you don't need
to worry about async-signal safety as you do in a normal signal handler!
Jon Baggott
I hit this problem with a utility class I was writing which implemented a
generic timer capability using SIGALRM. The approach I took was to install a
signal handler that just blocked the signal in the interrupted context and
then resent it. Thus if any threads were not blocking SIGALRM, the handler
would be invoked to block the signal in that thread, and shortly there would
only be the sigwait() left. It seems to work, but also seems rather kludgy.
Here's the code, anyone want to trample on it for me?
void initialize ( void )
{
sigset_t sigset;
struct sigaction act;
// Set a handler to catch, block and resend SIGALRM signals delivered to
// other threads already running
sigemptyset(&sigset);
act.sa_sigaction = (void(*)(int, siginfo*,
void*))unblocked_alarm_catcher;
act.sa_mask = sigset;
act.sa_flags = SA_SIGINFO | SA_RESTART;
sigaction(SIGALRM, &act, NULL);
// Other stuff omitted
}
void unblocked_alarm_catcher ( int signal,
siginfo_t* sip,
ucontext_t* uap )
{
// Make sure we caught the right signal
if (signal == SIGALRM )
{
// Block the SIGALRM signal from this thread by modifying the sigmask
in
// the catching thread's context
sigaddset(&uap->uc_sigmask, SIGALRM);
// Resend the signal
kill(getpid(), SIGALRM);
// Restore the active thread's context. We do this instead of a normal
// return as otherwise the saved signal mask would be restored over
the
// modified one
setcontext(uap);
// No return from setcontext
}
else
{
// Should never get here
return;
}
}
Dave Butenhof
> I hit this problem with a utility class I was writing which implemented a
> generic timer capability using SIGALRM. The approach I took was to install a
> signal handler that just blocked the signal in the interrupted context and
> then resent it. Thus if any threads were not blocking SIGALRM, the handler
> would be invoked to block the signal in that thread, and shortly there would
> only be the sigwait() left. It seems to work, but also seems rather kludgy.
> Here's the code, anyone want to trample on it for me?
Clever, and intriguing, and it might even work. There are a couple of things to
watch out for, though.
1. Despite casual mention of using setcontext() (and even longjmp()) from
within signal handlers, neither function is on the list of async-signal
safe functions. Technically, you shouldn't do that. (Yeah, the standard's
"inconsistent by implication", but, "so what?" ;-) )
2. I wouldn't bet much cash that setcontext() will actually work correctly
with threads on all (or even most) implementations. Remember, first off,
that there are currently few UNIX98 implementations, and UNIX95 explicitly
precludes the use of threads. POSIX does not define the meaning or use of
that third signal handler parameter, or getcontext/setcontext and friends.
Even for UNIX98, this is not going to be a commonly used "feature" and I
would expect it to be way way down on the list of issues to investigate
(nevermind resolve) for implementors. Someone recently suggested that one
shouldn't use pthread_exit() from the main thread, because his experience
was that it didn't work on many implementations (including Solaris, though
I don't know if he's correct in this). That's explicitly and clearly
required by the standard, and is an obvious and common feature. If its
true that some haven't gotten this right, don't bet the rent money that
they've got contexts working cleanly with threads!
3. Given that you're depending on UNIX98 rather than POSIX already, you could
substantially simplify your signal handler, and remove the shady/risky
areas, by declaring your signal handler with the SA_NODEFER flag, which
will prevent the handler from masking the signal -- and from restoring the
previous signal mask on return. Then you can simply mask the signal.
(Technically, you can't, because pthread_sigmask() isn't async-signal safe
and sigprocmask() is "undefined" in a threaded process. But in practice
it's far more reasonable to expect that sigprocmask() will be identical to
pthread_sigmask() than to count on setcontext() working!)
4. You're playing "tag", if something in the process is creating threads
dynamically, or if any threads might remove SIGALRM from their mask.
(Especially, of course, threads you don't control.) You may bounce the
signal around a lot of times before it gets where you want it to get -- or
it may never get there.
5. Signal handlers are completely non-modular. Lots of code plays with them,
despite the old rule-of-thumb that only the main program should do so.
Once someone zaps your SIGALRM handler, you're out of luck. In particular,
the definition of sigwait() explicitly allows that it may change the
signal action. Even if you reset it immediately on return from sigwait,
you've got a window where the default (or some other, unspecified) action
may be in effect. Even if the implementation of sigwait() restores the
prior handler before returning (much less if you do it yourself after
return), there might be a window where no, or some unspecified, handler is
in effect. I don't know if anyone does this. LinuxThreads probably changes
the handler, though, because its threads are really processes, each can
have independent signal handlers. (It has a protocol to sync up on
sigaction() changes, but could, and probably should, avoid this for
sigwait().)
Yeah, sure, what else can you do? But the real point is that the signal model
is hard to use, and that the introduction of threads makes it even harder to
use, often to the point where it's practically impossible. You're ALWAYS best
off finding another solution. Though, when you can't, you're stuck with life as
we know it. And as "drifting down the creek without a paddle" goes, your
approach beats many others I've seen. At the very least, it's an interesting
chunk of code that I intend to keep around. When I have a chance, I may even
check whether it works on my threads. ;-)
Stuart D. Gathman
>
> Yeah, sure, what else can you do? But the real point is that the signal model
> is hard to use, and that the introduction of threads makes it even harder to
> use, often to the point where it's practically impossible. You're ALWAYS best
> off finding another solution. Though, when you can't, you're stuck with life as
> we know it. And as "drifting down the creek without a paddle" goes, your
> approach beats many others I've seen. At the very least, it's an interesting
> chunk of code that I intend to keep around. When I have a chance, I may even
> check whether it works on my threads. ;-)
I am trying to figure out a way to handle signals synchronously in a Java VM.
I have a thread calling sigwait() which reports supported signals
synchronously to Java. But I have no control over other threads in the VM -
so I can't get them to block the signals. The sneaky solution of blocking the
signal in a handler probably won't work in AIX - the man page says "Concurrent
use of sigaction and sigwait for the same signal is forbidden".
One idea is to have the handler notify the signal thread somehow - not
necessarily with a signal. Is there some kind of event queue that could be
called from a signal handler?
Another idea is to have the signal thread call sigsuspend. Then, if the
handler could determine whether the thread it interrupted is the signal
thread, it could block the signal all threads except the signal thread.
My project (access to selected parts of the posix API from Java) can be found
at:
Dave Butenhof
> Dave Butenhof wrote:
> >
> I am trying to figure out a way to handle signals synchronously in a Java VM.
> I have a thread calling sigwait() which reports supported signals
> synchronously to Java. But I have no control over other threads in the VM -
> so I can't get them to block the signals. The sneaky solution of blocking the
> signal in a handler probably won't work in AIX - the man page says "Concurrent
> use of sigaction and sigwait for the same signal is forbidden".
It cannot legally say that, and it may not be saying what it seems to. There's no
restriction in POSIX, or in UNIX98, against using both. However, POSIX does say that
calling sigwait() for some signal MAY change the signal action for that signal. If
you have a silly implementation that actually does this (there's no point except
with a simple purely user-mode hack like the old DCE threads library), then trying
to combine them may be pointless -- but it's not illegal. (And, by the way, if
you're using any version of AIX prior to 4.3, then you ARE using that very
"user-mode hack" version of DCE threads, and you're not really allowed to set signal
actions for any "asynchronous" signal.)
Of course, in practice, such distinctions between "forbidden" and "legal but
meaningless" aren't useful, so one could argue that the incorrect statement "is
forbidden" may not be entirely unjustified. ;-)
> One idea is to have the handler notify the signal thread somehow - not
> necessarily with a signal. Is there some kind of event queue that could be
> called from a signal handler?
You can call sem_post() from a signal handler. Therefore, you could have a thread
waiting on a semaphore (sem_wait()), and have the signal call sem_post() to awaken
the waiter.
> Another idea is to have the signal thread call sigsuspend. Then, if the
> handler could determine whether the thread it interrupted is the signal
> thread, it could block the signal all threads except the signal thread.
I don't think I understand what you mean here. One thread cannot block a signal in
other threads. And that "if" hiding in the phrase "if the handler could determine"
is a much bigger word that it might seem. You cannot do that using any portable and
reliable mechanism.
Patrick TJ McPhee
Dave Butenhof <bute...@zko.dec.com> wrote:
% to combine them may be pointless -- but it's not illegal. (And, by the way, if
% you're using any version of AIX prior to 4.3, then you ARE using that very
% "user-mode hack" version of DCE threads, and you're not really allowed to set signal
% actions for any "asynchronous" signal.)
Non, non, monsieur has become confused by the plethora of non-compliant
posix-ish thread libraries again! HP-UX before the mythical 10.30 is the
user-mode-hack version of DCE threads. AIX 4.1 and 4.2 have a kernel-mode
`draft 7' hack. AIX also has DCE threads, but I think they're built on top
of the kernel threads, too. AIX 3.2 might have had user-mode DCE threads.
Signal handling on the AIX `draft 7' threads is a bit different from
POSIX, but I don't remember the details at present.
Stuart D. Gathman
> > I am trying to figure out a way to handle signals synchronously in a Java VM.
> > I have a thread calling sigwait() which reports supported signals
> > synchronously to Java. But I have no control over other threads in the VM -
> > so I can't get them to block the signals.
> > One idea is to have the handler notify the signal thread somehow - not
> > necessarily with a signal. Is there some kind of event queue that could be
> > called from a signal handler?
>
> You can call sem_post() from a signal handler. Therefore, you could have a thread
> waiting on a semaphore (sem_wait()), and have the signal call sem_post() to awaken
> the waiter.
There is no sem_post in AIX 4.3. I did try calling semop() in the signal
handler - and this works great. The only problem is, this leaves the process
with a cleanup chore of removing the semaphore id - which is the kind of
problem I am trying to solve in the first place :-) I suppose I could use a
global semaphore for use by all JVMs. Timing of SignalEvent delivery is not
critical.
AIX 4.3 has pthread_cond_wait(). However, to use pthread_cond_signal() to
wakeup the signal thread without missing a SignalEvent requires that the
signalhandler acquire the mutex of the condition variable - which seems
dangerous. Can I safely acquire a mutex and call pthread_cond_signal() from a
signal handler?
Dave Butenhof
> In article <366BC692...@zko.dec.com>,
> Dave Butenhof <bute...@zko.dec.com> wrote:
>
> Non, non, monsieur has become confused by the plethora of non-compliant
> posix-ish thread libraries again! HP-UX before the mythical 10.30 is the
> user-mode-hack version of DCE threads. AIX 4.1 and 4.2 have a kernel-mode
> `draft 7' hack. AIX also has DCE threads, but I think they're built on top
> of the kernel threads, too. AIX 3.2 might have had user-mode DCE threads.
Ack, phoo. I hate it when I do that.
You're absolutely correct. And, yes, AIX prior to 4.1 (and back to some early 3.x) used
the stock, portable, generic-UNIX "DCE thread" user-mode library.
It's really great that "everyone" finally has POSIX threads. Unfortunately, I keep
answering questions about OLD versions. And, yeah, it's sometimes hard to keep them all
straight.
Dave Butenhof
> Dave Butenhof wrote:
>
> > > One idea is to have the handler notify the signal thread somehow - not
> > > necessarily with a signal. Is there some kind of event queue that could be
> > > called from a signal handler?
> >
> > You can call sem_post() from a signal handler. Therefore, you could have a thread
> > waiting on a semaphore (sem_wait()), and have the signal call sem_post() to awaken
> > the waiter.
>
> There is no sem_post in AIX 4.3. I did try calling semop() in the signal
> handler - and this works great. The only problem is, this leaves the process
> with a cleanup chore of removing the semaphore id - which is the kind of
> problem I am trying to solve in the first place :-) I suppose I could use a
> global semaphore for use by all JVMs. Timing of SignalEvent delivery is not
> critical.
No sem_post? It doesn't support POSIX semaphores? How... amusing.
Unfortunately for you, neither system V semaphores nor BSD semaphores are async-signal
safe in any respect. You cannot post either from a signal handler.
I suppose you could create a pipe, have a thread read() from the pipe (or select() on
it), and then have the signal handler write() to the pipe. (That's probably not much
heavier, or more expensive, than a system V semaphore.)
> AIX 4.3 has pthread_cond_wait(). However, to use pthread_cond_signal() to
> wakeup the signal thread without missing a SignalEvent requires that the
> signalhandler acquire the mutex of the condition variable - which seems
> dangerous. Can I safely acquire a mutex and call pthread_cond_signal() from a
> signal handler?
You cannot call any pthread functions from a signal handler. In particular, you cannot
lock a mutex or signal a condition variable. (Actually, DCE threads, because it didn't
have and couldn't rely on POSIX semaphores, and, in any case, at that point sem_post
had not yet been defined to be async-signal safe, provided a
pthread_cond_signal_int_np() function that COULD signal a condition variable from a
signal handler. It actually set an atomic indication to the thread library scheduler so
that a condition variable waiter would be awakened at some, undefined, future time.
Furthermore, to avoid the "wakeup waiting" race, it posted a "pending wake" on the
condition variable so that the next waiter would return immediately. For binary
compatibility reasons, the Digital UNIX implementation of POSIX threads also provides
this function -- but for portability you should always use POSIX semaphores instead.)
It may be that AIX 4.3 has a POSIX version of pthread_cond_signal_int_np(). Presumably
they must continue to support that "feature" in their DCE thread interface, and
presumably that interface is layered on top of POSIX threads, meaning their POSIX
threads must provide for a pending wake. But, even if it does, they don't necessarily
expose or document an interface except through the DCE thread library. You'd be much
better off trying a different approach.
Darius S. Naqvi
>
> Lee Jung Wooc wrote:
>
> > Any one please help to redirect signal to the mainthread or
> > any idea on how to make the signal to process is handled in
> > main thread context ?
>
> As Patrick McPhee has already suggested, I recommend that you stop relying on
> a signal handler for this. To expand a little on his advice, begin by masking
> SIGUSR2 in main(), before creating any threads. Then create a special thread
> that loops on the sigwait() function, waiting for occurrences of SIGUSR2. (If
> the signal is not masked in ALL threads, then it may "slip through" somewhere
> while the signal thread is not waiting in sigwait() -- for example, while it's
> starting, or while it's responding to the previous SIGUSR2.)
>
Does the signal become pending in the sigwaiter thread in that case?
To be clear: suppost that a given signal is blocked in all threads,
and one thread sigwait()'s on it. Suppose that the while the
sigwait()ing thread is not actually in sigwait(), that signal is sent
to the process. Is the signal then pending in the sigwait() thread,
so that the next call to sigwait() notices the signal?
I've been assuming that since a signal is received by only one of the
threads in which it is not blocked, it is not made pending in the
blocking threads *if* there exists a thread that is not blocking it.
In order to not lose any signals, it must then be the case that if
every thread is blocking a signal, then when a signal is sent to the
process, it is made pending in *every* thread. I.e., either one
thread receives the signal and it is not made pending in any thread,
or the signal is pending in every thread. Is this true? (I don't
have a copy of the standard, but the book "Pthreads Programming" from
O'Reilly and Associates is silent on this matter.)
--
Darius S. Naqvi email: d...@myrias.com
Myrias Software Corp. Phone: (403) 435-1000
Suite 206, 9644 54th Ave. Fax: (403) 436-2999
Edmonton, Alberta T6E 5V1 http://www.myrias.com
Jeff Denham
> Dave Butenhof <bute...@zko.dec.com> writes:
>
> >
> > Lee Jung Wooc wrote:
> >
> > > Any one please help to redirect signal to the mainthread or
> > > any idea on how to make the signal to process is handled in
> > > main thread context ?
> >
> > As Patrick McPhee has already suggested, I recommend that you stop relying on
> > a signal handler for this. To expand a little on his advice, begin by masking
> > SIGUSR2 in main(), before creating any threads. Then create a special thread
> > that loops on the sigwait() function, waiting for occurrences of SIGUSR2. (If
> > the signal is not masked in ALL threads, then it may "slip through" somewhere
> > while the signal thread is not waiting in sigwait() -- for example, while it's
> > starting, or while it's responding to the previous SIGUSR2.)
> >
>
> Does the signal become pending in the sigwaiter thread in that case?
> To be clear: suppost that a given signal is blocked in all threads,
> and one thread sigwait()'s on it. Suppose that the while the
> sigwait()ing thread is not actually in sigwait(), that signal is sent
> to the process. Is the signal then pending in the sigwait() thread,
> so that the next call to sigwait() notices the signal?
If *all* threads have the signal blocked, the the signal remains
pending against the process. The next thread that makes
itself able to receive the signal, either by unblocking the
pending signal in it signal mask or by calling sigwait,
will receive the pending signal.
>
>
> I've been assuming that since a signal is received by only one of the
> threads in which it is not blocked, it is not made pending in the
> blocking threads *if* there exists a thread that is not blocking it.
> In order to not lose any signals, it must then be the case that if
> every thread is blocking a signal, then when a signal is sent to the
> process, it is made pending in *every* thread. I.e., either one
> thread receives the signal and it is not made pending in any thread,
> or the signal is pending in every thread. Is this true? (I don't
> have a copy of the standard, but the book "Pthreads Programming" from
> O'Reilly and Associates is silent on this matter.)
Signals sent to a process never "pend" against a thread. They can
only be pending against the process, meaning, as I explained above,
that any qualified thread can eventaully take the signal.
Only per-thread signals, sent via pthread_kill() can be pending
against a thread that has the signal blocked.
Externally, it's not that complicated. Internally, it can interesting....
__________________________________________________
Jeff Denham (jde...@brighttiger.com)
Bright Tiger Technologies: Resource-management software
for building and managing fast, reliable web sites
See us at http://www.brighttiger.com
125 Nagog Park
Acton, MA 01720
Phone: (978) 263-5455 x177
Fax: (978) 263-5547