<div dir="ltr">On Fri, Jul 19, 2013 at 9:02 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 18 Jul 2013, at 13:08, Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>> wrote:<br>

<br>
>> Wouldn't this approach (appending to a compilation database) have issues with filesystem contention and/or write atomicity in multicore/distributed builds (without involving a "real database" for the database storage)?<br>

><br>
> On Unix systems we can handle that via file locks. On windows we'd need a windows expert :P<br>
<br>
</div>Adding a mutex does not solve the problem of contention, it just eliminates races.  It still adds a serialising step to an inherently parallel process, and you should ask Amdahl why this is a bad idea.<br></blockquote>
<div><br></div><div>Well, for example, we can spawn a process that writes to the compilation db in the background from the driver, and if we assume that C++ compilations are long compared to writing a line of text to a file, we get that:</div>
<div>a) finishing off the build will be independent of finishing writing to the compilation db, thus, the impact on the build is negligible</div><div>b) the compilation db will probably be finished writing before the build finishes (as each step probably finishes writing to the compilation db before the step finishes)</div>
</div></div></div>