From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12675 invoked by alias); 19 Nov 2008 01:39:16 -0000 Received: (qmail 7838 invoked by uid 48); 19 Nov 2008 01:37:55 -0000 Date: Wed, 19 Nov 2008 01:39:00 -0000 Message-ID: <20081119013755.7837.qmail@sourceware.org> From: "tom dot honermann at oracle dot com" To: glibc-bugs@sources.redhat.com In-Reply-To: <20070704013541.4737.nmiell@comcast.net> References: <20070704013541.4737.nmiell@comcast.net> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug libc/4737] fork is not async-signal-safe X-Bugzilla-Reason: CC Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2008-11/txt/msg00055.txt.bz2 ------- Additional Comments From tom dot honermann at oracle dot com 2008-11-19 01:37 ------- (In reply to comment #13) > Tom's suggestion: "Another possible solution for this problem would be to just > not call atfork registered handlers at all if fork is called from within the > context of a signal handler." > > ... seems to be what the IEEE interpretation recommends and I've thought as well > that it might be a potential solution. > > Ulrich will have to decide whether this is an approach he'd accept. Thanks for the links Ryan! Does anyone have any suggests for how a thread can determine that it is running in a signal handler? Does glibc maintain a thread specific indicator that a thread is running a signal handler? I've been looking at the glibc code (struct pthread in particular) and I don't see an obvious indicator there. -- http://sourceware.org/bugzilla/show_bug.cgi?id=4737 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.