Date: Sun, 31 May 1998 20:58:43 -0700 (PDT) From: Jason Evans <jasone@canonware.com> To: freebsd-hackers@FreeBSD.ORG Subject: sigprocmask() and threads question Message-ID: <Pine.BSF.3.96.980531193754.13137C-100000@mozart.canonware.com>
next in thread | raw e-mail | index | archive | help
After doing some profiling of some multithreaded code I'm developing under
FreeBSD, I decided to take a look at the code to see why even for
single-threaded applications, more than half the time is spent in
sigprocmask().
As near as I can tell, every time any of the pthread_* functions are
called, the bodies of the pthread_* functions are wrapped in such a way
that all signals are blocked while executing. This makes sense to me if
we're worried about being in an inconsistent state (in the pthreads
library) when a signal is delivered. Is this in fact why signals are
blocked? Perhaps we need to correctly set the signal stack before
allowing signal delivery?
So, here are some ideas for which someone probably has good technical
reasons not to use:
==========================================================================
Suppose that the pthreads library puts wrappers around the signal
functions, such that when the user program installs a signal handler, the
pthreads library merely makes a note of it and sets up an internal signal
handler to catch whatever signals the user program specified. Now, make
sure that the internal signal handler is intelligent enough to handle a
signal at any time. When a signal is caught that should actually be
caught by the user's signal handler, either:
1) a) Get to a consistent internal state.
b) Fake a signal handler stack frame, and whatever else needs to be
done, and deliver the fake signal to the user's signal handler.
or
2) a) Get to a consistent internal state.
b) Uninstall the internal signal handler for the signal we're currently
dealing with.
c) raise() the signal again.
d) After the signal has been caught and dealt with by the user's signal
handler, re-install the internal signal handler.
==========================================================================
Block all signals, then check for pending signals every so often (how
often is often enough?). If there are any pending signals, unblock the
signals, call sigsuspend(), then block the signals again.
==========================================================================
I expect there are some difficulties in the details of these approaches,
perhaps even some impossibilities, as well as some possible fallacies. If
so, why won't they work? It seems like a good thing to me to do some extra
work once in a while to avoid having to block and unblock signal delivery
so often.
(Disclaimer: I don't have a clue about thread implementations. Forgive my
ignorance. =) )
Jason
Jason Evans
Email: [jasone@canonware.com]
Web: [http://www.canonware.com/~jasone]
Home phone: [(650) 856-8204]
Work phone: [(408) 774-8007]
Quote: ["Invention is 1% inspiration and 99% perspiration" - Thomas Edison]
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?Pine.BSF.3.96.980531193754.13137C-100000>