From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22133 invoked by alias); 21 Oct 2008 05:13:45 -0000 Received: (qmail 19739 invoked by uid 48); 21 Oct 2008 05:12:26 -0000 Date: Tue, 21 Oct 2008 05:13:00 -0000 Message-ID: <20081021051226.19738.qmail@sourceware.org> From: "nmiell at comcast dot net" 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-10/txt/msg00052.txt.bz2 ------- Additional Comments From nmiell at comcast dot net 2008-10-21 05:12 ------- (In reply to comment #2) > I am no glibc hacker, and I am not sure how to fix this bug. If the locking is > needed, perhaps signals should be blocked while the lock is held? Unfortunately, that's only a partial solution -- applications generally expect to get their signals, even if they're in the bowels of the memory allocator. The original thing that inspired this bug entry was a SIGSEGV in malloc() leading to an attempt to fork and exec GNOME's bug-buddy leading to a deadlock. Masking signals would prevent this valid usage scenario and annoy users. And this is completely ignoring the performance impact of two system calls for every malloc operation. -- 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.