Re: kernel thread as real threads..

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