[Pvfs2-developers] terminating state machines

[Phil Carns]

> 
> I don't see why the two have to be dependent for this to work.  Do  you 
> mean by the parent posting a job, the state machine stepping code  would 
> handling the actual posting?  I was assuming that the parent  state 
> action could just call job_concurrent_sm_post (or whatever its  called).
> 
> Could it be similar to the request scheduler job posting code?  The  
> parent state action could call job_concurrent_sm_post with an array  of 
> the child sms, which just calls sm_post and adds the parent sm and  its 
> array to an operation queue.  Then a job_concurrent_sm_test  function 
> could test for completion of a parent sm by looking at all  the sms in 
> the array to see if they completed.  The job_testcontext  code would 
> have to be modified of course (maybe rework the  
> do_one_test_cycle_req_sched function to also test parent sm jobs),  but 
> all of that still seems to be independent of the state machine  code 
> (i.e. someone could use the state machine code separately and  drive 
> state machines using something other than the job framework).   I don't 
> know if all that makes sense in the context of the changes  you've made, 
> but that's what I had in mind when I suggested posting a  job for the 
> parent.

I think I follow what you are describing, but I am not entirely sure. 
If so, I think there is one advantage to the approach that Walt has been 
hashing out thus far.  I think that what Walt is describing is 
event-driven, in a sense.  No one has to actively look to see if all of 
the children have finished.  Instead, the children each send 
notification (by calling a release function or manually decrementing a 
counter) in their completion function, with the parent eventually 
getting a single notification (representing all of the children) through 
the existing job completion queue mechanism.

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.

I think you are right though, that you could pull off your version 
without the the children actually having to make a job_* call.

-Phil