[Pvfs2-developers] terminating state machines

[Walter B. Ligon III]

Phil Carns wrote:
>> I think I'm getting voted down here, so I should probably just  
>> shutup, but I don't think in practice we're going to have that many  
>> child state machines that iterating through the list is at all  
>> costly.  I'm arguing for simpler mechanisms that fit in with the job  
>> subsystem over something more fancy and possibly slightly better  
>> performing.
> 
> 
> Well, as far as the number of SMs goes, I would rather not risk it.  I 
> still hope this is lightweight enough that we could eventually use it in 
> more places that would generate a lot of children (like a re-architected 
> sys-io implementation), though I don't know if that will pan out in 
> practice.  I got bitten by a similar assumption in the flow protocol- it 
> used to track all of its posted operations for testing rather than 
> relying on someone to notify it of completion.  Admittedly the flow 
> protocol is a more obvious case and I should have known better, but at 
> the time it seemed reasonable :)
> 
>>> I think that the way that you describe would work fine too, but it  
>>> would require a little more active work to check the status of the  
>>> array of child SMs and would require more code to keep track of them.
> 
> 
>> Probably a bit more code yes, but it seems cleaner than keeping  
>> around backpointers and checking for parents.  Instead of driving all  
>> state machines from one place, this event notification scheme  
>> essentially replaces the last child state machine with the parent,  
>> which seems like a bit of hack and harder to debug.
> 
> 
> I think I'm lost now.  What do you mean by replace?  The states are 
> still isolated, jobs trigger the transitions, only one state action gets 
> executed at a time, there still may be a time gap between completion of 
> any given child and when the parent picks up processing again, and there 
> are still frames.  I think both approaches will look the same when 
> running unless I missed something.  If Walt puts a longjmp() in there we 
> can both hit him over the head.

What? What?  How else would I do it?  ;-)

> 
> I think having a pointer to the parent actually improves debugability 
> (though I'm not sure this approach actually requires it, all you really 
> need is either a job descriptor or a pointer to a counter).  If I have a 
> state machine that does something bad or gets stuck it would be nice to 
> be able to work backwards to find out who invoked it, without having to 
> search for it in a seperate data structure.
> 
> I don't mean to keep struggling with this issue- I honestly think that 
> both approaches are pretty good, and if Walt implements it the way I 
> think he is going to, then 95% of developers won't notice the difference 
> anyway.  At this point I am mostly hammering away to make sure I am not 
> missing a larger issue...
> 
> -Phil

-- 
Dr. Walter B. Ligon III
Associate Professor
ECE Department
Clemson University