From owner-freebsd-hackers Sun May 31 21:00:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA22066 for freebsd-hackers-outgoing; Sun, 31 May 1998 21:00:28 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mozart.canonware.com (canonware.com [206.184.206.112]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA22055 for ; Sun, 31 May 1998 21:00:21 -0700 (PDT) (envelope-from jasone@canonware.com) Received: from localhost (jasone@localhost) by mozart.canonware.com (8.8.8/8.8.7) with SMTP id UAA14062; Sun, 31 May 1998 20:58:44 -0700 (PDT) (envelope-from jasone@canonware.com) X-Authentication-Warning: mozart.canonware.com: jasone owned process doing -bs Date: Sun, 31 May 1998 20:58:43 -0700 (PDT) From: Jason Evans Reply-To: Jason Evans To: freebsd-hackers@FreeBSD.ORG Subject: sigprocmask() and threads question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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