<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 31, 2013 at 1:35 PM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank" class="cremed">klimek@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think the sequential part of that step should be in the core code, but the parallelization will be in a (small) tool. This is also where special-case logic for custom networked file systems or strange version control systems would fall in.</blockquote>
</div><br>I really disagree. I don't know why we wouldn't aim to eventually have the core clang logic know all the necessary tricks to scalaing all aspects of this up. It shouldn't be sequestered like this.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Consider, if you have the ability to do any amount of parallelism in the tool, you'd often like to pipeline the analysis and the updating of files, all while maintaining de-dup coherency etc. This would essentially require the same code to be managing both the running of the tool and the writing of the updates. In the case where you *don't* serialize the edits through some other layer, I think you still will want this, and thus it belongs in common shared library code.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Naturally parallelism within a process of this kind (or any kind) of this kind is a long way off. I just don't want to not be thinking about it in terms of what the end goal looks like.</div>
</div>