From owner-freebsd-threads@FreeBSD.ORG  Thu Aug  3 18:44:59 2006
Return-Path: <owner-freebsd-threads@FreeBSD.ORG>
X-Original-To: freebsd-threads@freebsd.org
Delivered-To: freebsd-threads@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id E82D516A4E7;
	Thu,  3 Aug 2006 18:44:59 +0000 (UTC)
	(envelope-from phk@phk.freebsd.dk)
Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 814AF43D46;
	Thu,  3 Aug 2006 18:44:59 +0000 (GMT)
	(envelope-from phk@phk.freebsd.dk)
Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2])
	by phk.freebsd.dk (Postfix) with ESMTP id BE8DC170C5;
	Thu,  3 Aug 2006 18:44:57 +0000 (UTC)
To: Daniel Eischen <deischen@freebsd.org>
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
In-Reply-To: Your message of "Thu, 03 Aug 2006 14:34:04 -0400."
	<Pine.GSO.4.64.0608031417260.13543@sea.ntplx.net> 
Date: Thu, 03 Aug 2006 18:44:56 +0000
Message-ID: <49575.1154630696@critter.freebsd.dk>
Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-threads@freebsd.org
Subject: Re: threads/101323: fork(2) in threaded programs broken. 
X-BeenThere: freebsd-threads@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Threading on FreeBSD <freebsd-threads.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>, 
	<mailto:freebsd-threads-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-threads>
List-Post: <mailto:freebsd-threads@freebsd.org>
List-Help: <mailto:freebsd-threads-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>,
	<mailto:freebsd-threads-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Aug 2006 18:45:00 -0000

In message <Pine.GSO.4.64.0608031417260.13543@sea.ntplx.net>, 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

That would go a long way towards a "works if you're careful"
implementation.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.