On Mon, 2005-09-12 at 18:07 -0700, Paul Menage wrote:
> >
> > I think it is ok to assign the task to the default class if the parent
> > is also dying. comments anybody ? (it will also remove the fear of the
> > recursive loop :)
>
> I'd much rather have the task go to the parent if the destination
> class is dying.
>
> I want to use CKRM for job tracking; all processes in a job will be in
> a CKRM class, and each of these classes will be children of a single
> parent class. I need to be able to kill all the processes in a job;
> this is inherently racy, since a process could be forking at the point
> when I kill the processes and delete the class.
>
> If such forked processes classified into the parent, then I can safely
> say that any processes listed in the parent class are stray processes
> belonging to dead jobs, and I can kill them. If they're reclassified
> to the default class in that situation then I have no way of
> identifying them.
>
Valid point. Agreed.
> >
> > >
> > > >
> > > > Any logic to use a different newcls should be placed before the block of
> > > > code that sets the task class(not after).
> > > >
> > >
> > > It is - the code that sets the task class in the general case is
> > > directly after the while loop that I added.
> >
> > In my mind, newcls is the appropriate new class before the block :)
> > -----------
> > /* Take out of old class and drop the oldcore. */
> > if ((drop_old_cls = (curcls != NULL))) {
> > class_lock(class_core(curcls));
> > :
> > :
> > }
> > -----------
> >
> > but I agree that functionally you are right.
> >
> > Did you do it for holding the lock ?
>
> Yes.
>
> > If so, it can be simplified by
> > making 'dead' an atomic variable, it will also help solve the ABBA
> > problem i 've mentioned above.
>
> I don't think 'dead' can be a simple atomic variable - the "check
> dead/add task" needs to be atomic with respect to the "mark dead"
> otherwise we can have the race:
>
> A checks "dead" on class C
> B sets "dead" on class C
> B reclassifies tasks from class C (maybe none?)
> A adds self to C
Valid race. agreed.
>
> Paul
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> ckrm-tech mailing list
> https://lists.sourceforge.net/lists/listinfo/ckrm-tech
>
--
----------------------------------------------------------------------
Chandra Seetharaman | Be careful what you choose....
- [EMAIL PROTECTED] | .......you may get it.
----------------------------------------------------------------------
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech
