On 06.10.2006, at 19:38, Matthew Dillon wrote:
The basic problem being solved here is that a signal sent to a
process
group can wind up not being propogated to a newly fork()ed child
if it
occurs just before or during the fork(). In order to fix the
problem
we have to do two things:
i.e. when it occurs during the parent process is in the kernel, busy forking.
(1) We have to interlock new signal delivery to a process group
until
the fork1() code can add the new child to the process group. This
is accomplished by adding a lockmgr lock to the pgrp structure.
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 group3. now check pending deadly signals for the parent. if there are some, remove the child from the process group again and dispose the allocated proc, return and die.
from 2 on the child will receive signals for the process group, and until 3 the parent will not fork if there was a signal, so everything should be covered.
I have included a test program. With some playing around you should be able to see that children can be left alive and ticking after a ^C without the patch, and this hopefully will not occur after the patch.
I will try to come up with a patch or report back when I'm unable to do it without a lock. I just can't imagine that there has always been a race and nobody noticed.
cheers simon -- Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
PGP.sig
Description: This is a digitally signed message part
