[Pvfs2-developers] list-attr.sm refactored with pjmp

[Phil Carns]

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