kernel thread as real threads..
deischen at freebsd.org
Mon Jan 23 20:32:30 PST 2006
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.
More information about the freebsd-current