walt wrote:
Patch is attatched - based on the top of the trunk - it is only the changes to PINT_sm_frame
Thanks!
The way this works is when a SM DOES A PJMP it pushes it's children's frames. The children will each get their own SMCB, so if they run a PJMP they will have their own stack. So, when you return to a parent its frame will be at PINT_sm_frame(smcb, -1). It is probably a good idea to store the number of children somewhere in the parent's frame so you can pop them off.
Ok. I may throw a wrench into things with the last question in this email, but I think I follow what you are saying. I agree re: storing the number of children somewhere (I used a variable called "parallel_sms" to count them as I went in the listattr example).
We should create a #define for that -1 in state_machine.h You can access the children frames to retrieve results with indexes 0 .. N-1 or pop them off one at a time.
Cool. I suggest a PINT_FRAME_PARENT defined right beside PINT_FRAME_CURRENT.
There is no way to jump to the bottom of the stack. Nested machines do not change frames, so they aren't an issue.
Looking at your patch it still seems to me like -1 is going to go to the bottom-most frame of whatever frames are in the smcb, but I may just need to watch it on a running system to understand what's going on there better.
Re: the nested machines, though (and this may be the key to the confusion for me), what if an SM manually pushes a frame before calling the nested machine? I've done this in a couple of cases (none in trunk at this point) mainly for the sake of getting a new s_op structure so that the nested machine doesn't corrupt whatever the parent has going on its its own s_op structure. Most of the nested machines we have now operate as if they have the whole s_op to themselves.
-Phil _______________________________________________ Pvfs2-developers mailing list [email protected] http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
