[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: KDE/kdelibs/kate/buffer
From:       Andreas Pakulat <apaku () gmx ! de>
Date:       2010-04-09 21:16:09
Message-ID: 20100409211609.GG23433 () barmbek
[Download RAW message or body]

On 09.04.10 22:13:38, Christoph Cullmann wrote:
> Milian Wolff wrote:
> > On Friday 09 April 2010 21:00:18 Dominik Haumann wrote:
> >   
> >> On Friday 09 April 2010, Milian Wolff wrote:
> >>     
> >>> SVN commit 1112976 by mwolff:
> >>>
> >>> attempt to make blockForLine more reliable in a multi-threaded context
> >>>
> >>> still, the whole KateBuffer is inherently thread-unsafe and needs to be
> >>> fixed properly
> >>>       
> >> Reading this makes me feel uncomfortable... Whatever you mean by "fixed
> >> properly", maybe locks in the buffer? Uhh...
> >>     
> >
> > Hey,
> >
> > do you have a better way to fix this? I mean right now, no SmartRange must be 
> > used from a backgrounthread since e.g. isValid() will trigger a call to the 
> > buffer eventually (to make sure the column is actually valid).
> >
> > And anything else more direct that's related to the buffer is not thread safe. 
> > Would you rather have a single-thread-only Kate part just because it's easier? 
> > Really, I don't get it why this is such a big deal. What I do know is that in 
> > it's current form Kate from 4.5 is a major setback for any KDevelop user. In 
> > 4.4 smart ranges are crap, we all knew that, but at least we where at a point 
> > where most things simply worked...
> >
> > /me, still saddened
> >   
> No no no, in 4.4 the smart ranges are still broken, will crash like
> wanted...

As far as I understood, it works quite a lot better than current kate
from 4.5.

> Btw., even locking the whole buffer won't help, it emits signals, you
> can't tell what people do with them, then you get deadlocks faster then
> you ever wanted...
> 
> Really, qtcreator works with QTextDocument, not thread safe, works like
> a charm....

The problem is that we have a huge codebase relying on this stuff and
its currently broken. Porting that to something else is a major effort,
which means we're stuck with KDE 4.4 for at least 4.0 and potentially
KDevelop 4.1. Thats not an option, but the only way around that is
forking katepart and that would suck just as well.

Andreas

-- 
You never know how many friends you have until you rent a house on the beach.
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel
[prev in list] [next in list] [prev in thread] [next in thread]