KatePart + KDE 4.4 + QMutex & Co.

[David Nolden]

Am Dienstag 21 Juli 2009 10:50:32 schrieb Christoph Bartoschek:
> > It has nothing to do with parsing, but mainly with the highlighting. That
> > is something that Qt creator does not (yet) do at all. The highlighting
> > is very expensive, and thus it happens in a background thread.
> >
> > I agree that it would be good simplifying the whole thing somehow, in a
> > way that would reduce the cross-kate-kdevelop breakage risks.
>
> Would it be too slow to do the highlighting updates in the GUI thread by
> posting events from the highlighting thread to the GUI thread?
>
> If kate is specified to be single thread only then it should be used in
> this way. Otherwise it seems that no one takes care to have it thread-safe.

Kate is not specified to be single-threaded, that's why the API's around 
KTextEditor::SmartRange are built using the smart-lock etc.

That does make some parts of kate quite complicated error-prone internally, 
and it has taken really long to fix at least 99% of the multi-threading 
issues. 

As Hamish said, those multithreading issues will not be visible within kate, 
but only within applications actually using multithreading. That's good for 
the kate developers, but I personally hate that fact. ;-)

But the good thing is, that I haven't seen multithreading related problems in 
kate in recent times.

For the highlighting, some "update posting" mechanism could work, but does not 
necessarily have to. Another reason what the thread-safety is needed for right 
now, is to allow the background thread to temporarily 'lock' the state of the 
ranges, in order to warrant consistency and prevent user-interaction while the 
background is reading the range.

Changing away from that multi-threaded scheme would mean that the APIs would 
have to be changed, which is not possible until KDE5 (Other apps apart from 
KDevelop might rely on the APIs, for example kile).

Greetings, David