kernel thread as real threads..

[Julian Elischer]

Daniel Eischen wrote:

>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.
>  
>

It's not a case of kernel state so much as the state of user space.
Of course there is some course kernel state involved, such as if
one thread does a fork while the other is mmaping pages or setting signals.