<div dir="ltr"><div dir="ltr">On Thu, Jan 9, 2020 at 9:44 AM Amar Tumballi &lt;<a href="mailto:amarts@gmail.com">amarts@gmail.com</a>&gt; wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 9, 2020 at 1:38 PM Xavi Hernandez &lt;<a href="mailto:jahernan@redhat.com" target="_blank">jahernan@redhat.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Sun, Dec 22, 2019 at 4:56 PM Yaniv Kaul &lt;<a href="mailto:ykaul@redhat.com" target="_blank">ykaul@redhat.com</a>&gt; wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif">I could not find a relevant use for them. Can anyone enlighten me?</div></div></blockquote><div><br></div><div>I&#39;m not sure why they are needed. They seem to be used to keep the unserialized version of a dict around until the dict is destroyed. I thought this could be because we were using pointers to the unserialized data inside dict, but that&#39;s not the case currently. However, checking very old versions (pre 3.2), I see that dict values were not allocated, but a pointer to the unserialized data was used.</div></div></div></blockquote><div><br></div><div>Xavi,</div><div><br></div><div>While you are right about the intent, it is used still, at least when I grepped latest repo to keep a reference in protocol layer. </div><div><br></div><div>This is done to reduce a copy after the dictionary&#39;s binary content is received from RPC. The &#39;extra_free&#39; flag is used when we use a GF_*ALLOC()&#39;d buffer in protocol to receive dictionary, and extra_stdfree is used when RPC itself allocates the buffer and hence uses &#39;free()&#39; to free the buffer.</div></div></div></blockquote><div><br></div><div>I don&#39;t see it. When dict_unserialize() is called, key and value are allocated and copied, so  why do we need to keep the raw data after that ?</div><div><br></div><div>In 3.1 the value was simply a pointer to the unserialized data, but starting with 3.2, value is memdup&#39;ed. Key is always copied. I don&#39;t see any other reference to the unserialized data right now. I think that instead of assigning the raw data to extra_(std)free, we should simply release that memory and remove those fields.</div><div><br></div><div>Am I missing something else ?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>I think this is not needed anymore. Probably we could remove these fields if that&#39;s the only reason.</div></div></div></blockquote><div><br></div><div>If keeping them is hard to maintain, we can add few allocation to remove those elements, that shouldn&#39;t matter much IMO too. We are not using dictionary itself as protocol now (which we did in 1.x series though).</div><div><br></div><div>Regards,</div><div>Amar</div><div>---</div><div><a href="https://kadalu.io" target="_blank">https://kadalu.io</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif">TIA,</div><div style="font-family:arial,helvetica,sans-serif">Y.<br></div></div>
_______________________________________________<br>
<br>
Community Meeting Calendar:<br>
<br>
APAC Schedule -<br>
Every 2nd and 4th Tuesday at 11:30 AM IST<br>
Bridge: <a href="https://bluejeans.com/441850968" rel="noreferrer" target="_blank">https://bluejeans.com/441850968</a><br>
<br>
<br>
NA/EMEA Schedule -<br>
Every 1st and 3rd Tuesday at 01:00 PM EDT<br>
Bridge: <a href="https://bluejeans.com/441850968" rel="noreferrer" target="_blank">https://bluejeans.com/441850968</a><br>
<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-devel</a><br>
<br>
</blockquote></div></div>
_______________________________________________<br>
<br>
Community Meeting Calendar:<br>
<br>
APAC Schedule -<br>
Every 2nd and 4th Tuesday at 11:30 AM IST<br>
Bridge: <a href="https://bluejeans.com/441850968" rel="noreferrer" target="_blank">https://bluejeans.com/441850968</a><br>
<br>
<br>
NA/EMEA Schedule -<br>
Every 1st and 3rd Tuesday at 01:00 PM EDT<br>
Bridge: <a href="https://bluejeans.com/441850968" rel="noreferrer" target="_blank">https://bluejeans.com/441850968</a><br>
<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-devel</a><br>
<br>
</blockquote></div></div>
</blockquote></div></div>