[Pvfs2-developers] terminating state machines

[Phil Carns]

>> 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.

Yeah, you are right- it doesn't have any impact on the underlying 
mechanism.  Its just some extra programming practice we can try to 
establish later for SM users.

-Phil