From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31411 invoked by alias); 14 Oct 2011 14:06:06 -0000 Received: (qmail 31403 invoked by uid 22791); 14 Oct 2011 14:06:04 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 14 Oct 2011 14:05:49 +0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sources.redhat.com Subject: [Bug libc/4737] fork is not async-signal-safe Date: Fri, 14 Oct 2011 14:06:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bugdal at aerifal dot cx X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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: 2011-10/txt/msg00084.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=4737 Rich Felker changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugdal at aerifal dot cx --- Comment #21 from Rich Felker 2011-10-14 14:05:00 UTC --- It should be noted that this bug, even if irrelevant to future POSIX revisions, can easily be fixed. Either recursive or error-checking mutexes will work, but they must also be reentrant, i.e. the mutex must be in a consistent state with the owner and lock count correct immediately after the atomic operation to take the lock completes successfully. This is most easily achieved by putting the owner id in the atomic lock field and using a zero-based lock count (where the first lock operation does not increment the count and the last unlock does not decrement it). The only additional cost is looking up the caller's thread id, if this is not already performed in the existing locking code... but for some archs that may be prohibitively costly... -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.