From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 9 17:39:38 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 682871065670; Fri, 9 Jan 2009 17:39:38 +0000 (UTC) (envelope-from prvs=julian=25380973a@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 9D3718FC0C; Fri, 9 Jan 2009 17:39:37 +0000 (UTC) (envelope-from prvs=julian=25380973a@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.87]) by smtp-outbound.ironport.com with ESMTP; 09 Jan 2009 09:39:09 -0800 Message-ID: <49678BBC.8050306@elischer.org> Date: Fri, 09 Jan 2009 09:39:08 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Brian Fundakowski Feldman References: <20090109031942.GA2825@green.homeunix.org> <20090109053117.GB2825@green.homeunix.org> <4966F81C.3070406@elischer.org> <20090109163426.GC2825@green.homeunix.org> In-Reply-To: <20090109163426.GC2825@green.homeunix.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 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 17:39:38 -0000 Brian Fundakowski Feldman wrote: > On Thu, Jan 08, 2009 at 11:09:16PM -0800, Julian Elischer wrote: >> 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. >>> >> Practically, you can't go threaded again after a fork >> (by which I mean creating new threads or use things >> like mutexes etc.) in any posix system I know of. >> >> It would require that: >> The forking thread stop until: >> Every other thread has released every resource it owns >> and reports itself to be in a "safe quiescent state", >> or at least report every resource it owns, especially >> locks, >> and >> After the fork: >> The child, post fork, to take ownership of all >> of them, and free them. >> >> You might be able to do that in a simple >> threaded program, but consider then that the libraries may have >> threads running in them of which you are unaware, and that >> some of the resources may interract with resources owned by the >> forking thread. >> >> Add to this that there may be a signal thrown into this mix as well >> >> (signals are the bane of thread developement) > > Well, I wouldn't mind showing all of you what I can of what I had been doing > with the background threads -- it works pretty well modulo this particular > malloc lock bug. Due to it being inappropriate to share library resources > between a child and parent for an open socket connection, I always considered > the only "safe" behavior to be going single-threaded for the duration of the fork > processes in both the parent and child, and the pthread_atfork(3) hooks have been > sufficient to do so. ahhhh well going single threaded for the duration of the fork, changes everything! >