From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12356 invoked by alias); 9 Jul 2008 03:55:25 -0000 Received: (qmail 12344 invoked by uid 22791); 9 Jul 2008 03:55:25 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 09 Jul 2008 03:55:08 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 8265C3C33E; Tue, 8 Jul 2008 20:55:06 -0700 (PDT) Subject: Re: [non-stop] 08/10 linux native support From: Michael Snyder To: Daniel Jacobowitz Cc: Pedro Alves , gdb-patches@sourceware.org In-Reply-To: <20080709034706.GA21192@caradoc.them.org> References: <200806152205.49241.pedro@codesourcery.com> <200806252217.25796.pedro@codesourcery.com> <20080625221220.GB5723@caradoc.them.org> <200807020434.50543.pedro@codesourcery.com> <20080707182009.GE1778@caradoc.them.org> <1215573936.3549.126.camel@localhost.localdomain> <20080709034706.GA21192@caradoc.them.org> Content-Type: text/plain Date: Wed, 09 Jul 2008 03:55:00 -0000 Message-Id: <1215575706.3549.140.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00125.txt.bz2 On Tue, 2008-07-08 at 23:47 -0400, Daniel Jacobowitz wrote: > On Tue, Jul 08, 2008 at 08:25:36PM -0700, Michael Snyder wrote: > > Fork is undefined in a multi-threaded program. > > According to what? Not POSIX - otherwise there wouldn't be > pthread_atfork. > > I think even vfork is valid in multithreaded programs; in any case, it > behaves sensibly with NPTL. Well, I should perhaps say for, is *not well* defined in a multi-threaded program -- at least not defined consistently. I had to research this at my last job but one, and it was very difficult to find anything that definitively says that it is UN-defined... but try to find Posix explicitly saying what *should* happen if a multi-threaded program forks. Here's IEEE std 1003.1: A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. [THR] [Option Start] Fork handlers may be established by means of the pthread_atfork() function in order to maintain application invariants across fork() calls. [Option End] The issue is that only the thread that actually calls fork() will be duplicated in the child, but the mutexes (which may have been held by another thread) will be duplicated, and therefore the child may deadlock.