<p>The big lock wouldn't eliminate multithreading at all.</p>
<p>For example in the c++ support, it is needed only once at the beginning of a parse job to get the include paths, and maybe a few times during the code completion, which is quite tightly coupled to the UI anyway. Ok, it would also be required for using the new smart-ranges for highlighting, but that could be combined into one single locking per parsed open document, and thus wouldn't be critical.</p>

<p>The important task is just to make sure the lock is used as seldomly as possible, and to make sure that all the heavy-lifting is done in a long continuous phase without the lock. That is easy for c++ support at least.</p>

<p>Greetings, David</p>
<p><blockquote type="cite">Am 09.06.2010 20:00 schrieb "Esben Mose Hansen" <<a href="mailto:kde@mosehansen.dk">kde@mosehansen.dk</a>>:<br><br><p><font color="#500050">On Wednesday 09 June 2010 18:12:47 Christoph Cullmann wrote:<br>
> Then you are stuck more or less with ...</font></p>Both can be done in parallel, actually. If a BKL were implemented, it would<br>
then be possible to walk around and eliminate each usage of it (except in the<br>
main thread)<br>
<font color="#888888"><br>
--<br>
Kind regards, Esben<br>
</font><p><font color="#500050"><br>-- <br>KDevelop-devel mailing list<br><a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br><a href="https://barney.cs.uni-potsdam.de/mailma.">https://barney.cs.uni-potsdam.de/mailma.</a>..</font></p>
</blockquote></p>