[Pvfs2-developers] terminating state machines

[Phil Carns]

Walter B. Ligon III wrote:
> 
> OK, guys, I have another issue I want input on.  When child SMs 
> terminate they have to notify their parent.  The parent has to wait for 
> all the children to terminate.  So I've been thinking to use the job 
> subsystem for this: the parent would post a job to wait for N children,
> and each child would post a job, the last one releasing the parent.
> 
> Now I see two ways to implement this - one is to implement this directly 
> in the state machine code.  The parent simply stops running (because it 
> does not schedule a job yet returns DEFERRED).  Each child decrements a 
> counter, and when it hits 0 the parent is restarted.  This is a little 
> ugly because the waiting parent is not being held on any list or queue 
> (up to now all waiting SMs are in the job subsystem), also the last 
> terminating child becomes the parent as it starts executing the parent 
> code.  Things can get weird when one SM starts children that start 
> children, and so on.
> 
> Now the other way to implement this is with the job subsystem as I 
> suggested above.  Much cleaner except for one thing:  up to now the 
> state machine subsystem has had no dependency at all on the job 
> subsystem.  If we do it this way, this function only works with the job 
> system intact.  I'd prefer not to do this, but it does seem the 
> cleanest, most logical means.

I like the job approach.  I guess this is an extra dependency because 
the sms would be calling these particular job functions implicitly, 
rather than relying on the state functions to handle those posts and 
releases?  We definitely haven't done that before, but at least in this 
case the job function that the sm infrastructure would be depending on 
is the simplest one in the arsenal :)  It shouldn't be hard for someone 
to reimplement that particular functionality if they wanted to use the 
state machine mechanism in another project.

If you weren't planning on these job calls to be implicit, then I'm not 
sure where the extra dependency is- we already use jobs to trigger all 
of the other "normal" transitions.

This reminded me of a question, though- is there going to be a standard 
mechanism for the children to report each of their independent error 
codes to the parent sm?  Or do the children need to just keep a 
reference to the parent sm structure and manually fill in an array or 
something?

I guess I have a broader question of how data that the children generate 
(like a handle value or an attr structure) gets transferred to the 
parent.  Does the parent copy this stuff from the child after the child 
finishes, or does the child copy it to the parent before it exits?    I 
think we talked about this before at some point but I forgot what the 
plan is.  It would be nice if we made the developer define macros or 
something to dictate what the input parameters need to be filled in when 
invoking a child and what output parameters can be retrieved when it 
finishes.  Otherwise it starts getting tricky to remember what fields 
need to be set in the sm structure before kicking something off.

-Phil

-Phil