<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
That's unfortunately not the same, since while you're swapping the<br>
second value, a different thread could swap the first for a different<br>
value again.<br></blockquote><div><br></div><div>I get your point.</div><div>Generally what comes to the mind in such circumstances is blocking the other thread some way like mostly by spin locks.</div><div>But at the same time, if I use spin locks here, there is no point of using compare and swap.</div><div>So need to figure out a better solution to change variables staying with cas.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
That should be possible using atomic fetch-and-add [1]. This may end up<br>
increasing the storage by more than we need, but that's not a problem.<br>
<br>
The problem I see is that we actually need to do the truncation and<br>
remapping at some point. We should end up in a situation where the size<br>
is actually larger than the file/memory block.<br></blockquote><div><br></div><div>I understand. Many checks can be put to avoid this but at last they will make the main reason of this code which is optimisation useless.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Unfortunately ftruncate(2) is all that we have, and without writing<br>
kernel code I don't see a way to do this.<br></blockquote><div><br></div><div>Actually I had kind of interpose to  __dt_ftruncate() and __dt_mmap in mind that time. I should be more precise in words, sorry for that. </div><div>These would allow us to  make the checks beforehand but the same thing again, doing so much would just erase the optimisation benefit we are planning.</div><div>Although I am not sure about that because memory expansion would be required very less if we predict to a good extent the memory required.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br><br>
Can you pastebin a main.log of a build that fails like this?<br></blockquote><div><br></div><div><a href="https://pastebin.com/FVdp4WTw">https://pastebin.com/FVdp4WTw</a></div><div><br></div><div>I guess now this was for some similar reason as path or co-existence.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
<br>
[1] <a href="https://en.wikipedia.org/wiki/Fetch-and-add" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Fetch-and-add</a><br><br></blockquote><div>Thanks.</div><div><br></div><div><br></div><div>Regards,</div><div>Mihir </div></div></div>
</div></div>