On 05/30/2007 09:45 PM, Jim Jagielski wrote: > > On May 30, 2007, at 2:57 PM, Ruediger Pluem wrote: > >> >> >> On 05/30/2007 08:10 PM, Jim Jagielski wrote: >> >>> >>> On May 29, 2007, at 5:28 PM, William A. Rowe, Jr. wrote: >>> >>>> >>>> Essentially, PID tables need to move from the score to a local process >>>> list only in the parent, and unshared. That would solve the 80/20 of >>>> this entire class of issues. >>>> >>> >>> Yes... Of course, it doesn't even need to be that extensive. >>> If the parent process simply keeps in local storage a >>> list of PIDs and before it does anything to the child >>> process (send signal), it checks that the PID in the >>> scoreboard is also in its own list, and only >>> continues if it is.... This means that the scoreboard >>> stays as is and the parent process just needs a >>> small list of pid's added to it, plus some minor >>> logic. >> >> >> This is also my thought on this. Maybe the logic could be extended >> somewhat so that the parent cross checks / sanity checks the number of >> pids in its local storage and the number of active pids (a.k.a "non >> empty" >> slots) in whatever state they are every time it decides that it needs >> to start additional childs / kill childs. This should avoid / reduce >> issues #1 / #4. >> > > :) My thoughts exactly... > > The only issue with pulling parent out of scoreboard is, > of course, the backwards compatibility with modules that > may be interested in it...
Sorry for being confused now. I thought the idea was to have an additional local pid list in the parent for cross / sanity checking. The scoreboard remains as it is (including the pids). So what could modules possible miss after the patch? Regards Rüdiger
