: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
