<p>Why should the foreground lock be responsible for any UI blocking? Technically, it allows us the _minimal_ amount of UI blocking possible. I don't understand where you want to save anything with another technique.</p>

<p>What you write regarding responsiveness doesn't make sense. Just to repeat it: _everything_ that is done with the foregroundlock held, _has to_ be done in the foreground! Kate API is not thread-safe! So there is simply nothing you can gain by using another pattern. You have to do those calls in the foreground anyway. The only thing one could do is making more API thread-safe. Then the foreground lock wouldn't be required for that API, still no need for another "pattern".</p>

<p>Anyway, this lock is mostly used for ligh-weight calls like editor->getText(), and I am very sure that it doesn't have _anything_ to do with nonresponsive UI. The duchain locks are much more problematic regarding this.</p>

<p>How Qt-Creator works is not interesting, it's an entirely different architecture, and that it's faster has nothing to do with this "pattern", but rather with the verbosity of its stored data, and with the level of processing. The fact that the kdev4 language architecture seems _still_ lightyears ahead of qt-creator makes this comparison even less interesting.</p>

<p>Regarding debugging: The foreground lock is very simple. The log I read shows that thiago/till _nearly_ understood its internals after just an hour or something. Apart from that, it doesn't seem to have bugs anyway. ;-)</p>

<p>So before you invest work into changes, please at least explain how you want to gain something. Until now this all seems like a witch hunt, with the only argument "I've heard the best way of doing it is X. I don't know the difference, but it's different, so it must be better."</p>

<p>Greetings, David</p>
<p><blockquote type="cite">Am 09.01.2011 22:24 schrieb "Milian Wolff" <<a href="mailto:mail@milianw.de">mail@milianw.de</a>>:<br><br>David Nolden, 07.01.2011:<br>
<p><font color="#500050">> Hi, I've read your IRC discussion about the foreground lock on:<br>> <a href="http://webcache.googleuserconten.">http://webcache.googleuserconten.</a>..</font></p>First up, thanks for this email, really. I appreciate it greatly. I just<br>

wanted to add some comments.<br>
<p><font color="#500050"><br>> - What's it's sense?<br></font></p><snip><br>
<p><font color="#500050"><br>> The second solution would be doing those actions _before_ forking into<br>> the background by collec...</font></p>Imo the first paragraph is not really noteworthy, but the last one explains<br>

why the ForegroundLock is neat. It made the port much easier (and might be<br>
used in different places in future). I still hope for the day where we rewrite<br>
the parse jobs though to use the other pattern you describe. And I think it is<br>
possible and would probably lead to a much more responsible user interface.<br>
KDevelop *is* noticably slower when writing, and the ForegroundLock (or the<br>
SmartMutex) are imo the #1 culprits for this. If we can dump parsejobs into<br>
the background and let them do their job completely separated from the rest<br>
(beside the frequent DUChain locks), I bet it will be noticably more pleasent.<br>
<br>
Anyhow, besides this purely theoritical performance gain, there is another<br>
point: Maintainability. I am still, even after the lengthy discussions and<br>
hours spent on it, not confident to fix bugs in the lock - if there are any<br>
left. Otoh, the memory pattern is easy and straight forward to debug. That<br>
alone is for me personally a huge advantage.<br>
<p><font color="#500050"><br>> The ForegroundLock is basically simply a generalization of the third<br>> solution that requires nea...</font></p>I'd like to at least assert on the duchain lock. Other locks are not global<br>

enough to be tested there.<br>
<p><font color="#500050"><br>> - Why the ugly nested class?<br>> Sometimes the foreground starts nested event loops. Those are ugly...</font></p>Is it really not doing *anything*? Some events will still bubble though, or?<br>

Also, while there is already a short comment in the code, could you maybe add<br>
this more elaborated explanation/justification?<br>
<p><font color="#500050"><br>> - Why the custom recursion counter?<br>> Only this way we can unlock the foreground lock completely ...</font></p>I think Atomic is required. If N threads do the check above and one of them<br>

changes holderThread, it might result in undefined behavior, or not? Isn't<br>
this exactly the kind of thing AtomicInt is supposed to be used for? Anyways,<br>
I'm sure Helgrind warned about this read before (without the AtomicInt).<br>
<p><font color="#500050"><br>> - Isn't it slow? We're blocking the foreground!<br>> Only simple and fast operations should be perfo...</font></p>Right, but it's left to be seen whether a *good* approach to the memory<br>

pattern wouldn#t be better still. I continue to think so until the glory day<br>
someone implements it ;-)<br>
<p><font color="#500050"><br>> - Issues<br>> About the _only_ issue that I know of regarding the ForegroundLock is<br>> that any QObje...</font></p>I didn't mean to rewrite the ForegroundLock, I meant the whole parsing API and<br>

I'm perfectly aware that this is borderline madness. I won't tackle it anytime<br>
soon, so no worries ;-) But as you can see above I still assume the memory<br>
pattern would be the better approach. It works *very* well in QtCreator, I<br>
cannot see how it shouldn't work for us. But this is the usual "I'd think so"<br>
kind of argument. I have never done anything alike before so I might be<br>
totally wrong, who knows. I just got lots of feedback by a number of people I<br>
respect for their programming knowledge, all of them urging me to use the<br>
memory pattern. I doubt they are all wrong. And just to make sure this is not<br>
misunderstood: I love how you implemented this and ported KDevelop. I bet we<br>
would still be changing API instead of concentrating on bug fixes and<br>
releasing KDevelop 4.2 soon (which reminds me, I should start creating the<br>
tarballs for RC1).<br>
<br>
So let me finish it with a big thank you again. You did tremendously good<br>
work, and I do hope you continue to come up with such interesting and effectic<br>
solutions to our problems.<br>
<font color="#888888"><br>
--<br>
Milian Wolff<br>
<a href="mailto:mail@milianw.de">mail@milianw.de</a><br>
<a href="http://milianw.de" target="_blank">http://milianw.de</a><br>
</font><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/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
<br></blockquote></p>