From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15286 invoked by alias); 19 Nov 2008 16:23:24 -0000 Received: (qmail 6292 invoked by uid 48); 19 Nov 2008 16:22:08 -0000 Date: Wed, 19 Nov 2008 16:23:00 -0000 Message-ID: <20081119162208.6291.qmail@sourceware.org> From: "rsa at us dot ibm 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/msg00056.txt.bz2 ------- Additional Comments From rsa at us dot ibm dot com 2008-11-19 16:22 ------- (In reply to comment #14) > (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. Tom, perhaps you can post this question to the libc-help mailing list and reference this bugzilla? -- 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.