From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: For review: timer_create.2 Date: Wed, 11 Feb 2009 09:26:43 +0100 Message-ID: <1234340803.23438.107.camel@twins> References: <4990DE09.7020801@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4990DE09.7020801-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Sender: linux-man-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Michael Kerrisk Cc: "linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Ulrich Drepper List-Id: linux-man@vger.kernel.org On Tue, 2009-02-10 at 14:53 +1300, Michael Kerrisk wrote: > static void > handler(int sig, siginfo_t *si, void *uc) > { > /* Note: calling printf() from a signal handler is not > strictly correct, since printf() is not async-signal-safe; > see signal(7) */ > > printf("Caught signal %d\n", sig); > print_siginfo(si); > signal(SIG, SIG_IGN); > } Is that actually safe to do? I can remember getting into deadlocks by doing this some few years ago. The problem was that glibc uses a mutex to guard its memory area for the malloc memory pool, and signals can come in while the main thread of execution is within that mutex, if at that point the signal handler also tries to use anything using malloc (here, I was thinking printf() might), you've got a deadlock. One thing I always enjoyed about the QNX man-pages was that it explicitly states which functions are and are _NOT_ signal safe, iow which functions can be reliably used from signal handler context. -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html