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
_______________________________________________
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
