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