ForegroundLock

[Milian Wolff]

David Nolden, 09.01.2011:
> 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.
> 
> 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".
> 
> 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.

Exactly, they are lightweight. So we can do them once before pushing the job 
into the background and "forget" about it. But really, this is just my 
personal (theoretical) opinion, that it *might* result in a better perceived 
performance. If it is really the case or not is left to be seen.

> 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.

Right, I didn't talk about features or anything. Just about that they use the 
memory pattern and their editor is fast (yes no highlighting and all that, 
maybe it really is all that is to that). But don't take this too seriously 
until I really start coming up with patches and results that compare both 
approaches.

> 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. ;-)

It was more than an hour, esp. for me and till. And we cannot assume we will 
always have people as proficient as till and thiago around. So lets just hope 
for it being bug free indeed :)

> 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."

If I'd ever feel like rewriting such deep core architecture, I'd definitely do 
extensive benchmarking to actually find out whether there is anything better 
or not. Generally, it should be easy to write some benchmarks comparing these 
two patterns. But again: I won't start this anytime soon - we have much more 
important stuff to do than this.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20110109/eaae07f1/attachment.sig>