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@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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@xxxxxxxxxxx>
> 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@xxxxxxxxxxx
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel@xxxxxxxxxxx
>> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
>
>
--
Matthew McKeen
matthew@xxxxxxxxxxx
Matthew McKeen
matthew@xxxxxxxxxxx
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
