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

[Sam Lang]

On Mar 13, 2008, at 11:33 AM, 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).

That state machine could operate on a completely separate structure  
(instead of an s_op), and we could push/pop that struct onto the stack  
everywhere we just to that state machine.  Might even have convenience  
functions for initializing the struct.  To be honest though, I would  
probably just leave it 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.

Sounds like we need a tree structure instead of a queue to manage the  
frames.
-sam

>
>
> -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: smime.p7s
Type: application/pkcs7-signature
Size: 2417 bytes
Desc: not available
Url : http://www.beowulf-underground.org/pipermail/pvfs2-developers/attachments/20080313/fed25f38/smime.bin