[Pvfs2-developers] terminating state machines

[Walter B. Ligon III]

Phil Carns wrote:
> 
>> Phil, first your questions:  The parent will push a "frame" onto a 
>> stack for each child it is starting.  A frame is everything that used 
>> to be in either a s_op or sm_p on the server or client, except for the 
>> stuff that actually runs the SM (now in an smcb).  The parent can pass 
>> in anything it wants by filling in the fields appropriately.  When 
>> each child runs that struct will appear to be its "current" frame.  
>> Each child can leave that frame in any condition it wants, with any 
>> values of buffers the child wants to leave for the parent.  After the 
>> children are done the parent can pop each frame off the stack and do 
>> what it wants with it. Thus there is plenty of flexibility on how you 
>> want to handle passing things in and out, all under control of the 
>> server or client code.
> 
> 
> Sounds great.
> 
>> As for providing macros for setting up and tearing down frames, we can 
>> certainly do that.  I'm not sure hoe much that really helps, but we 
>> can do it.
> 
> 
> I think it would be nice to help prevent programmer error.  The same 
> thing was done with the protocol request structures (see all the 
> PINT_SERVREQ_*_FILL macros used in the client sms).  If you have a 
> macro, then neglecting to pass in one of the required input fields 
> results in a compiler error.  Otherwise the compiler can't help to tell 
> you if you have set all of the frame fields that you were supposed to 
> set.  There is no technical advantage, it just makes setting the fields 
> a little more foolproof.
> 
> Same goes for the output of a frame after completion, although I'm not 
> sure what the macro would look like there, or if it is possible. 
> Probably a given frame will have several fields - some are input, some 
> are output, some are scratch area for the state functions, etc.  Someone 
> coming along later trying to reuse the SM may not know (without some 
> tricky code digging) which fields are the output fields that it can 
> count on to be correctly filled in after completion.   For example, 
> maybe there is a field called "parent_handle" in there- is it filled in? 
>  If so, is it guaranteed to be filled in, or did I just happen to get it 
> this time because of the steps path the sm took?   I don't know what the 
> best way is to make this explicit, maybe some kind of macro, maybe 
> putting a special prefix on the names of the output fields, any other 
> ideas?  Maybe we just use comments :)

OK, I see what you mean.  I think that's kind of a syntax level thing - 
IOW I think if affects the underlying mechanism.  So yeah, we should 
have that and we'll work on that once the mechanism works.

> 
>> Now, an implementation question - one approach to this job/counter 
>> thing is to have two job calls, one for the parent, and one of the 
>> children. Another approach is for the parent to simple set a counter 
>> and not call anything.  The children come along, decrement the count, 
>> and if zero, call job_null() to awaken the parent.  Requires no 
>> modification in the job layer, minimizes dependency.  What do you 
>> think?  Should the job layer have more of a roll, or keep it minimum?
> 
> 
> Not a big deal to me either way. Especially if all of these calls are 
> implicit in the state processing code - no one is really going to see 
> them normally anyway.

OK, I think everyone has weighed in on this, and I think I'll use the 
minmal method.  The only real diff is Sam's preference not to use a 
counter.  We can go around on that, but I'm leaning towards a counter, 
at least for the initial implementation.
> 
> -Phil

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