cvs commit: src/lib/libkse/thread thr_kern.c

[Julian Elischer]

Julian Elischer wrote:
> Landon Fuller wrote:
>>
>> On Jan 17, 2008, at 17:10, Julian Elischer wrote:
>>
>>> I gather it is the PARENT that hangs here?
>>>
>>
>> Parent continues, the child hangs in fork().
> 
> no the child hangs in mutex_lock_common()
> 
> please do a ktrace of the program and send that to me
> 
Here's my guess as to what is happening:
thos is not based on code..

thread 1 calls the dummy fork(3)
thread 2 calls the dummy fork(3)
thread 1 calls fork(2), (the syscall, from within the dummy fork)
thread2 calls fork(2) (the real one in the kernel)
      thread 1 proceeds
      thread 2 blocks on a VM lock until thread 1 completes
      kernel duplicates the memory space
thread 1 returns from fork(2)
thread 1 takes out mutex X inside dummy fork(3)
      thread 2 proceeeds in the kernel on forking.
      kernel duplicates the memory space (including mutex X)
thread 2 returns from kernel and looks for mutex X
thread 2 in client tries to take out mutex X inside dummy fork(3) and 
waits.
thread 1 releases mutex X
thread 2 proceeeds
================================
in child1 thread1 runs fine.
in child2 thread2 waits for thread 1 to drop the mutex
  (there is no thread1)


the question is: what is the mutex being acquired AFTER forking?

Dan?