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

[walt]

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
> Pvfs2-developers at beowulf-underground.org
> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: walt.vcf
Type: text/x-vcard
Size: 229 bytes
Desc: not available
Url : http://www.beowulf-underground.org/pipermail/pvfs2-developers/attachments/20080313/b72a2218/walt.vcf