Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Jan 2006 23:32:28 -0500 (EST)
From:      Daniel Eischen <deischen@freebsd.org>
To:        Peter Jeremy <PeterJeremy@optushome.com.au>
Cc:        freebsd-current@freebsd.org
Subject:   Re: kernel thread as real threads..
Message-ID:  <Pine.GSO.4.43.0601232319140.20562-100000@sea.ntplx.net>
In-Reply-To: <20060124020137.GW25397@cirb503493.alcatel.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 24 Jan 2006, Peter Jeremy wrote:

> On Mon, 2006-Jan-23 20:38:46 -0500, Daniel Eischen wrote:
> >On Tue, 24 Jan 2006, Peter Jeremy wrote:
> >
> >> On Mon, 2006-Jan-23 19:59:02 -0500, Daniel Eischen wrote:
> >> >POSIX specifies that only 1 thread (the forking thread) is present
> >> >after a fork.
> >>
> >> Just to clarify, I presume you are talking about only one thread
> >> existing in the child process and the parent's threads still exist as
> >> they did before the fork().  If fork() arbitrarily killed all the
> >> threads in the parent process, that would be a real PITA.
> >
> >Correct, I assumed we were talking about the child process.
>
> My understanding of Robert's issue was the case where a parent has
> multiple threads, one thread does a fork() whilst the remaining
> threads are not blocked.  If the remaining threads are executing
> whilst fork() is copying the process address space, then the child
> will could inherit a confused (partially indeterminate) copy of the
> parent's address space, depending on what the other threads have
> been doing.

I think that's OK.  The only thing that is guaranteed safe (in the
child) after a fork from a multi-threaded process are the
async-signal-safe functions.  If a process has aio active,
it shouldn't assume anything about the childs state after a
fork.  I think it's only important that the forking thread
continues on normally in the child.  OTOH, if there is a
possibility of some inconsistent kernel state that will affect
the child if it calls any of the async-signal-safe functions
or one of the exec() functions, that should be avoided.

-- 
DE




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0601232319140.20562-100000>