[Gluster-devel] Reuse of frame?

[Anand Avati]

Does your code wait for both clients to unwind so that it merges the two
replies before it unwinds itself? You typically would need to keep a call
count (# of winds) and wait for that many _cbk invocations before calling
STACK_UNWIND yourself.

If you are not waiting for both replies, it is possible that the frame
pointer got re-used for second call before second callback of first call
arrived.


On Mon, Jul 28, 2014 at 12:32 PM, Matthew McKeen <matthew at mmckeen.net>
wrote:

> I have a translator on the client stack.  For a particular getxattr I
> wind the stack to call two client translator getxattr fops.  The
> callback for these fops is the same function in the original
> translator.  The getfattr cli command calls two getxattr syscalls in
> rapid succession so that I see the callback being hit 4 times, and the
> original getxattr forward fop 2 times.  For both the 4 callbacks and 2
> forward fops the frame pointer for the translator is the same.
> Therefore, when I try and store a pointer to a dict in frame->local,
> the dict pointer points to the same dict for both fops and data set
> into the dict with the same keys ends up overwriting the values from
> the previous fop.
>
>
>
> On Mon, Jul 28, 2014 at 12:19 PM, Anand Avati <avati at gluster.org> wrote:
> > call frames and stacks are re-used from a mem-pool. So pointers might
> > repeat. Can you describe your use case a little more in detail, just to
> be
> > sure?
> >
> >
> > On Mon, Jul 28, 2014 at 11:27 AM, Matthew McKeen <matthew at mmckeen.net>
> > wrote:
> >>
> >> Is it true that different fops will always have a different frame
> >> (i.e. different frame pointer) as seen in the translator stack?  I've
> >> always thought this to be true, but it seems that with the
> >> release-3.6.0 branch the two quick getxattr syscalls that the getfattr
> >> cli command calls share the same frame pointer.
> >>
> >> This is causing havoc with a translator of mine, and I was wondering
> >> if this was a bug, or expected behaviour.
> >>
> >> Thanks,
> >> Matt
> >>
> >> --
> >> Matthew McKeen
> >> matthew at mmckeen.net
> >> _______________________________________________
> >> Gluster-devel mailing list
> >> Gluster-devel at gluster.org
> >> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
> >
> >
>
>
>
> --
> Matthew McKeen
> matthew at mmckeen.net
>
>
> --
> Matthew McKeen
> matthew at mmckeen.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140728/1f1cd126/attachment.html>