From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 9 15:52:07 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 957901065670; Fri, 9 Jan 2009 15:52:07 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 384AF8FC17; Fri, 9 Jan 2009 15:52:07 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id n09FaiSj012500; Fri, 9 Jan 2009 10:36:44 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Fri, 09 Jan 2009 10:36:44 -0500 (EST) Date: Fri, 9 Jan 2009 10:36:44 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Brian Fundakowski Feldman In-Reply-To: <20090109053117.GB2825@green.homeunix.org> Message-ID: References: <20090109031942.GA2825@green.homeunix.org> <20090109053117.GB2825@green.homeunix.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: hackers@freebsd.org, jasone@freebsd.org Subject: Re: threaded, forked, rethreaded processes will deadlock X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 15:52:07 -0000 On Fri, 9 Jan 2009, Brian Fundakowski Feldman wrote: > On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote: >> On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote: >> >>> It appears that the post-fork hooks for malloc(3) are somewhat broken such that >>> when a threaded program forks, and then its child attempts to go threaded, it >>> deadlocks because it already appears to have locks held. I am not familiar >>> enough with the current libthr/libc/rtld-elf interaction that I've been able >>> to fix it myself, unfortunately. >> >> There's really nothing to fix - according to POSIX you are only >> allowed to call async-signal-safe functions in the child forked >> from a threaded process. If you are trying to do anything other >> than that, it may or may not work on FreeBSD, but it is not >> guaranteed and is not portable. >> >> The rationale is that what is the point of forking and creating >> more threads, when you can just as easily create more threads in >> the parent without forking? The only reason to fork from a threaded >> process is to call one of the exec() functions. > > Well, it worked until the last major set of changes to malloc. For me, the point > was that I was able to have transparent background worker threads in any program > regardless of its architecture, using the standard pthread fork hooks. Could you > point me to the POSIX section covering fork and threads? If it's really not > supposed to work then that's fine, but there's an awful lot of code there dedicated > to support going threaded again after a fork. I don't know if this link will work for you, but you can start here: http://www.opengroup.org/onlinepubs/009695399/nframe.html "It is suggested that programs that use fork() call an exec function very soon afterwards in the child process, thus resetting all states. In the meantime, only a short list of async-signal-safe library routines are promised to be available." -- DE --