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

List:       kwrite-devel
Subject:    Re: KDE/kdelibs/kate/buffer
From:       Christoph Cullmann <cullmann () absint ! de>
Date:       2010-04-09 21:47:28
Message-ID: 4BBFA070.9040500 () absint ! de
[Download RAW message or body]

Andreas Pakulat wrote:
> 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.
>   
It just works by chance...

>   
>> 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.
>   
I can understand that you have problems with that, but really, there is
no other way than fix your use of it.
Kate part was not thread safe in KDE 4.x, never, ever.
That now some parts got more fragile is bad, but given that, there is no
way for anybody to do any
development at the part, as any chance will break kdevelop, as anything
can trigger races.

The new buffer is 10000 times better designed than the old, it is
faster, it is lighter, it is documented everywhere, it has tests in git...
Still it seems to break kdevelop, because it just uses the part in ways
not allowed.

I oppose any changes like the above caching of a var that just will hide
the bugs even more.
Yes, it helps a bit, but as soon as the user presses return in the wrong
time, even with the above fix,
it might just crash.

And no, locking is no option, how should it work? The whole part uses
references to the text lines via smart pointers, any change of such
lines while the part uses them will lead to crashs,  the other way
around, you
can be never sure in your thread that the main thread doesn't modify those.

Signals are emited, if we do locking, we will get deadlocks there, like
we have them atm already in corner cases.

I am sorry, I read your code for the whole du-chain stuff, and yes, it
is highly infected with uses of smart* everywhere for everything from
any thread...
What should I say, the smart code in kate part is still reason one for
all reported crashs (beside the global kdelibs kdirwatch problem in kde
4.4.0).
Even without thread it just is completly borked, the smartgroups don't
work, .....
And even worse: it is not documented how it should work at all, which
makes fixing impossible...

Greetings
Christoph

-- 
-------------------------------------- Christoph Cullmann ---------
AbsInt Angewandte Informatik GmbH      Email: cullmann@AbsInt.com
Science Park 1                         Tel:   +49-681-38360-22
66123 Saarbrücken                      Fax:   +49-681-38360-20
GERMANY                                WWW:   http://www.AbsInt.com
--------------------------------------------------------------------
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234

_______________________________________________
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]