Ruediger Pluem wrote: > > > > 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? >
Not sure where the confusion is... the idea is to keep the scoreboard exactly as-is (as noted above, pulling out the parent parts (pid), would be a major issue for backwards compatibility), and just add pid-checking logic (and a local store of pids) in the parent process. Thus, it's completely transparent and no changes to the scoreboard or any entities that use it (except for the mentioned parent-side checking, 'natch) :) "The only issue..." refers to the problems if we try to restructure the scoreboard instead, which is good for 2.4/3.0 but not for 2.2, 2.0 and 1.3... Any patches that tried to address the issue using that method would be problematic. Hence my thoughts to just have local storage for checking and keeping scoreboard as-is. -- =========================================================================== Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
