From owner-freebsd-threads@FreeBSD.ORG Thu Aug 3 20:10:23 2006 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18CE316A4DE for ; Thu, 3 Aug 2006 20:10:23 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBA2343D53 for ; Thu, 3 Aug 2006 20:10:20 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k73KAK4M021184 for ; Thu, 3 Aug 2006 20:10:20 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k73KAKHf021183; Thu, 3 Aug 2006 20:10:20 GMT (envelope-from gnats) Date: Thu, 3 Aug 2006 20:10:20 GMT Message-Id: <200608032010.k73KAKHf021183@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Daniel Eischen Cc: Subject: Re: threads/101323: fork(2) in threaded programs broken. X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 20:10:23 -0000 The following reply was made to PR threads/101323; it has been noted by GNATS. From: Daniel Eischen To: Poul-Henning Kamp Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-threads@freebsd.org Subject: Re: threads/101323: fork(2) in threaded programs broken. Date: Thu, 3 Aug 2006 16:04:49 -0400 (EDT) On Thu, 3 Aug 2006, Poul-Henning Kamp wrote: > In message , Daniel Eischen wr > ites: > >> No, that's not nearly enough. This has been discussed in >> -threads before. >> >> Forking from a multi-threaded program is just like an >> asynchronous signal in an unthreaded program. You have >> no idea what state any of the libraries or application data >> is in. > > ... Unless of course, the programmer too great care to make > sure he did, and therefore assumes that fork() will actually > be safe. > > In my case, I know the exact state of the entire process > and I know 100% certain that there are no locks held which > will affect the forked copy. > > ... except that holding all malloc's locks screws me over :-( > > I will agree that there is no "perfect" solution, but that is > not what I'm after, I'm after "works in controlled circumstances. > > I would argue that an implementation that does: > > hold any library locks we want to handle > fork > if (parent) > release those locks again > return > else > unlock all locks (since they cannot possibly > make sense in the child in a locked state) > return There's no easy way to hold all library locks. They are littered in libc and libpthread and the application doesn't have access to them. You would have to teach libc to record these locks and export a function to lib to lock and unlock these them. > That would go a long way towards a "works if you're careful" > implementation. -- DE