From owner-freebsd-current@FreeBSD.ORG  Tue Jan 24 02:30:26 2006
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
X-Original-To: freebsd-current@freebsd.org
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 835C916A41F;
	Tue, 24 Jan 2006 02:30:26 +0000 (GMT)
	(envelope-from julian@elischer.org)
Received: from a50.ironport.com (a50.ironport.com [63.251.108.112])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 42D7A43D46;
	Tue, 24 Jan 2006 02:30:26 +0000 (GMT)
	(envelope-from julian@elischer.org)
Received: from unknown (HELO [10.251.23.146]) ([10.251.23.146])
	by a50.ironport.com with ESMTP; 23 Jan 2006 18:30:25 -0800
X-IronPort-Anti-Spam-Filtered: true
Message-ID: <43D59141.4030701@elischer.org>
Date: Mon, 23 Jan 2006 18:30:25 -0800
From: Julian Elischer <julian@elischer.org>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
	rv:1.7.11) Gecko/20050727
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Daniel Eischen <deischen@freebsd.org>
References: <Pine.GSO.4.43.0601231954150.17167-100000@sea.ntplx.net>
In-Reply-To: <Pine.GSO.4.43.0601231954150.17167-100000@sea.ntplx.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-current@freebsd.org, Robert Watson <rwatson@freebsd.org>
Subject: Re: kernel thread as real threads..
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jan 2006 02:30:26 -0000

Daniel Eischen wrote:

>On Mon, 23 Jan 2006, Julian Elischer wrote:
>
>  
>
>>Robert Watson wrote:
>>
>>
>>well, the operation woudll continue for the parent only I woudl assume.
>>
>>    
>>
>>>(although davidxu is changing that)
>>>      
>>>
>>I'm not convinced that that multiple threads should be allowed to
>>proceed during a fork
>>but I can see that not allowing it is more a "foot shooting avoidance"
>>than a requirement.
>>it could be allowed that if you do a fork and allow multipel threads to
>>runat the same time
>>and end up with an inconsistant address space in the child, then you get
>>what you deserve.
>>:-)
>>    
>>
>
>POSIX specifies that only 1 thread (the forking thread) is present
>after a fork.  If you want all (or some subset) of the parent's
>threads to exist after a fork(), you must call it something
>else (use a flag to rfork?) and ensure it is not the default
>behavior.
>  
>
I'm not saying the others would survive, but that if they are running on 
other processors
at the moment when we duplicate the  address space, we may get a rather 
inconsistent
address space..  The current code handles this by forcing all other 
threads into
a suspended state before allowing the  fork() to proceeed and then 
allowing them
to continue (on the parent only) when the fork has completed.  There aer 
some cases when this
behaviour has been seen to cause problems and it has been suggested that
this is not a requirement.