Date: Tue, 5 Feb 2002 16:48:20 +1100 (EST) From: callum.gibson@db.com To: eischen@pcnet1.pcnet.com Cc: hackers@freebsd.org Subject: Re: pthread_sigmask problem Message-ID: <20020205054820.76300.qmail@merton.aus.deuba.com> In-Reply-To: <Pine.GSO.4.10.10202050010120.3489-100000@pcnet1.pcnet.com> from "eischen@pcnet1.pcnet.com" at Feb 05, 2002 12:26:39 AM
next in thread | previous in thread | raw e-mail | index | archive | help
Let me know if I should take this off list now since it's probably reached
its limit of interest for most people.
eischen@pcnet1.pcnet.com writes:
}> I figured it was just using the default action for these signals. So, am
}> I mistaken in thinking that SIG_BLOCK was supposed to ignore those signals
}> or is this a pthreads bug on FreeBSD? Or just an "undefined" behaviour
}> and a pthreads gotcha? It's worth noting that even with pthreads on Solaris
}> I get the behaviour I was expecting (ie the signals are ignored) using
}> either pthread_sigmask or sigprocmask.
}It's not clear to me that using pthread_sigmask should change
}the default behaviour that signals have on the process. Thread
}signal masks seem to be independent of installed signal handlers
}and default actions that signals have on the process.
Well, it depends on what it means to block a signal. From reading the manpage
it seems to indicate that delivery of these signals is deferred indefinitely
until a thread sigwaits for them or if a thread doesn't have them blocked.
Since I was doing this as the very first thing in the process (ie there
are no other threads), it would imply that all other threads created from
then on would also block those signals. This is certainly how it behaves on
Solaris. Haven't checked Linux but will report back if you're interested.
In practice, FreeBSD's thread library probably has internal threads operating
in the background which are there from the outset and don't inherit this
mask and it's _those_ threads which are taking delivery of the fatal signals.
}> Also, is it documented anywhere which signals will behave like this? It
}> seems like it would be all of them, as if the process still has an inherent
}> signal mask independent of the threads running, thus requiring signal
}> handlers to be installed for them. Hmm, it's a lot more verbose calling
}> sigaction for every signal rather than a single pthread_sigmask call.
}> I guess that's why we have for loops.
}See sigaction(2).
Yeah, doesn't really explain if the process is anything more than the
sum of its threads. Under Solaris that's all it is. A non-threaded process
is actually a process with a single thread. This is the state of the process
when I do the sigprocmask/thr_setsigmask/pthread_sigmask call. It's only
after you make your first call to the thread library proper (by creating
a new thread) that the background threads appear (this is on Solaris).
I suspect this is not how it works on FreeBSD - the method of compilation
even gives a clue to this (a special compiler directive). Even without making
any new threads a FreeBSD threaded program will probably have these internal
threads (I'm speculating here as I don't have the equivalent of pstack
to be able to check that). I guess it also has something to do with being
a userland implementation?
I guess the question boils down to: Should an application be able to operate
oblivious to the existence of internal threads? Does a process exist
apart from the threads that make it up?
Anyway, sigaction does the trick - it just seems superfluous on Solaris,
at least.
}>From your other email:
}> Doh! You can specify a set of signals with sigaction. Sorry about that.
}Nope, you can only install a handler for one signal at a time.
Spotted that just after I sent it but I figured replying to myself twice
in a row was Really Bad (tm). I was right the first time.
C
(c)2002 Callum Gibson callum.gibson@db.com
Global Markets IT, Deutsche Bank, Australia 61 2 9258 1620
### The opinions in this message are mine and not Deutsche's ###
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020205054820.76300.qmail>