:I think this must be possible without a lock. How about this: : :1. allocate new proc (may block) :2. add new proc to the process group :3. now check pending deadly signals for the parent. if there are some,=20= : :remove the child from the process group again and dispose the allocated=20= : :proc, return and die. : :from 2 on the child will receive signals for the process group, and=20 :until 3 the parent will not fork if there was a signal, so everything=20 :should be covered.
I think this would work, but there is a big problem... in order to process the pending signals fork1() must return ERESTART (just as it does in my patch). But returning ERESTART that deep into fork1()'s code means undoing a lot of allocations and other setup. It could turn into a mess. :I will try to come up with a patch or report back when I'm unable to do=20= : :it without a lock. I just can't imagine that there has always been a=20 :race and nobody noticed. : :cheers : simon I don't think the lock is a big issue, because signals are very rarely sent to a process group and that is the only time an exclusive lock is obtained. The lock obtained in fork1() is LK_SHARED so it will not serialize forks from multiple processes that happen to be in the same process group (such as occurs in a buildworld). Besides, we will probably need some sort of lock in the pgrp structure anyway once the MP work reaches it. -Matt