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