Patch is attatched - based on the top of the trunk - it is only the
changes to PINT_sm_frame
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.
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.
There is no way to jump to the bottom of the stack. Nested machines do
not change frames, so they aren't an issue.
Walt
Phil Carns wrote:
Ok. I have fixed that "only zero indexes work" issue in trunk too in
order to be able to index 0..N, but I didn't do anything beyond that
with it. If you have a patch with your sm code changes that we can go
ahead and push to trunk that would be great.
You might want to go ahead and consider merging some of these other
recent changes to trunk into your branch as well. Some things here from
about the 11th of this month and newer might be relevant for what you
are working on. There are some generic fixes to sm / pjmp
functionality, and also some cleanup of getattr_work that makes it a
little safer to call from other parents:
http://www.pvfs.org/fisheye/changelog/~br=MAIN,author=pcarns/PVFS
So would a -1 index get you the very outermost parent (ie, the bottom of
the stack)? In the more general case it may still be helpful to just
get to the level right before pjmp rather than all the way to the
bottom, particularly if the pjmp is issued from a nested machine.
-Phil
walt wrote:
Phil, I'll look at the code when I can. I'm interested in the
get_attr_work issue, we are calling that in the create_file request,
and we have also created a set_attr_work SM and will likely be
setting up some others in our work. At minimum we need to document
the parameters in the code. Whatever gets done here we will probably
want to make sure it gets replicated in the trunk as well as our branch.
Also, in our branch I have modified the parallel state machine code a
little to fix the problem you mentioned wrt getting the parent frame.
In the version we checked out of trunk, only a zero index could be
specified - otherwise an infinite loop resulted. Also, it seemed to
assume a positive index. I modified it to allow both positive and
negative indexes, so a -1 index would give you the parent frame, and
0..N gives the frames on top of the stack (which is actually circular).
Pretty simple mod actually, I can try to create a patch for it and you
can try it out.
Keep me up to date on that other issue.
Walt
Phil Carns wrote:
I needed to make some changes to list-attr.sm recently and realized
that it probably should really be redone now that we have parallel
nested machines available. listattr is a server operation that
retrieves attributes for a list of handles at once. The old version
duplicated logic from get-attr.sm, while the new version does a pjmp
to the nested pvfs2_get_attr_work_sm machine instead.
There are a few advantages to this approach:
- it gives us a complete example of pjmp in trunk
- we don't have to keep listattr code in sync with getattr, since
they now share the same core logic (listattr was already a little
behind)
- the list-attr.sm source code is much smaller now
- list-attr.sm should be faster now as well, because it is capable of
getting many trove operations queued up at once rather than iterating
through each of the getattr's (and waiting for completion of each) in
serial
I could stand some extra eyes to look at list-attr.sm and make sure
the implementation in trunk is sane. Here is a link if anyone wants
to look at it online:
http://www.pvfs.org/fisheye/browse/~raw,r=1.9/PVFS/src/server/list-attr.sm
There are two goofy bits of code marked with a "TODO" comment:
- Running pvfs2_get_attr_work_sm requires setting a variety of
undocumented parameters before launching it. I'm not sure how to
best clean this up (or if I should just let this slide for now).
- After the pjmp, it is a little hard to find the parent frame (which
is useful to have before popping the other frames so that you have
somewhere to store results). I ended up just iterating through the
frames looking for it, but I would like to find a nicer way to do
this too.
-Phil
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
--- pvfs2/src/common/misc/state-machine-fns.c 2008-03-13 15:00:40.000000000
-0400
+++ pvfs-cu/src/common/misc/state-machine-fns.c 2008-03-13 15:34:43.000000000
-0400
@@ -605,7 +605,7 @@
void *PINT_sm_frame(struct PINT_smcb *smcb, int index)
{
struct PINT_frame_s *frame_entry;
- struct qlist_head *next;
+ struct qlist_head *target;
if(qlist_empty(&smcb->frames))
{
@@ -616,15 +616,21 @@
}
else
{
- int i = 0;
-
- next = smcb->frames.next;
- while(i < index)
+ /* frame list is circular */
+ target = smcb->frames.next;
+ /* this handles negative indexes */
+ while(index < 0)
+ {
+ target = target->prev;
+ index++;
+ }
+ /* this handles positive indexes */
+ while(index > 0)
{
- i++;
- next = next->next;
+ target = target->next;
+ index--;
}
- frame_entry = qlist_entry(next, struct PINT_frame_s, link);
+ frame_entry = qlist_entry(target, struct PINT_frame_s, link);
return frame_entry->frame;
}
}
begin:vcard
fn:Walt Ligon
n:Ligon;Walt
org:Clemson University;ECE Department
adr;dom:;;;Clemson;SC;29634
email;internet:[EMAIL PROTECTED]
title:Associate Professor
tel;work:864-656-1224
x-mozilla-html:FALSE
version:2.1
end:vcard
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
