<div dir="ltr">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.<div>
<br></div><div>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.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, Jul 28, 2014 at 12:32 PM, Matthew McKeen <span dir="ltr"><<a href="mailto:matthew@mmckeen.net" target="_blank">matthew@mmckeen.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">I have a translator on the client stack. For a particular getxattr I<br>
wind the stack to call two client translator getxattr fops. The<br>
callback for these fops is the same function in the original<br>
translator. The getfattr cli command calls two getxattr syscalls in<br>
rapid succession so that I see the callback being hit 4 times, and the<br>
original getxattr forward fop 2 times. For both the 4 callbacks and 2<br>
forward fops the frame pointer for the translator is the same.<br>
Therefore, when I try and store a pointer to a dict in frame->local,<br>
the dict pointer points to the same dict for both fops and data set<br>
into the dict with the same keys ends up overwriting the values from<br>
the previous fop.<br>
<br>
<br>
<br>
On Mon, Jul 28, 2014 at 12:19 PM, Anand Avati <<a href="mailto:avati@gluster.org">avati@gluster.org</a>> wrote:<br>
> call frames and stacks are re-used from a mem-pool. So pointers might<br>
> repeat. Can you describe your use case a little more in detail, just to be<br>
> sure?<br>
><br>
><br>
> On Mon, Jul 28, 2014 at 11:27 AM, Matthew McKeen <<a href="mailto:matthew@mmckeen.net">matthew@mmckeen.net</a>><br>
> wrote:<br>
>><br>
>> Is it true that different fops will always have a different frame<br>
>> (i.e. different frame pointer) as seen in the translator stack? I've<br>
>> always thought this to be true, but it seems that with the<br>
>> release-3.6.0 branch the two quick getxattr syscalls that the getfattr<br>
>> cli command calls share the same frame pointer.<br>
>><br>
>> This is causing havoc with a translator of mine, and I was wondering<br>
>> if this was a bug, or expected behaviour.<br>
>><br>
>> Thanks,<br>
>> Matt<br>
>><br>
>> --<br>
>> Matthew McKeen<br>
>> <a href="mailto:matthew@mmckeen.net">matthew@mmckeen.net</a><br>
>> _______________________________________________<br>
>> Gluster-devel mailing list<br>
>> <a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
>> <a href="http://supercolony.gluster.org/mailman/listinfo/gluster-devel" target="_blank">http://supercolony.gluster.org/mailman/listinfo/gluster-devel</a><br>
><br>
><br>
<br>
<br>
<br>
--<br>
Matthew McKeen<br>
<a href="mailto:matthew@mmckeen.net">matthew@mmckeen.net</a><br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Matthew McKeen<br>
<a href="mailto:matthew@mmckeen.net">matthew@mmckeen.net</a><br>
</font></span></blockquote></div><br></div>