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

List:       kdevelop-devel
Subject:    Re: KatePart + KDE 4.4 + QMutex & Co.
From:       Hamish Rodda <rodda () kde ! org>
Date:       2009-07-16 0:57:04
Message-ID: 200907161057.04841.rodda () kde ! org
[Download RAW message or body]

On Sat, 11 Jul 2009 12:56:39 am Christoph Cullmann wrote:
> Hi,
>
> I just read again through the bugreports and the kate part code. It seems
> to me really over complex to have all this locking build into the part.
> Given a quick look at qtcreator, which parses the sources, too, they can do
> all the locking if at all outside of the qtextdocument/edit they use.
>
> Could you try to do so, too, by just locking the main thread on the rare
> occasions you change stuff on the part or handle the mutex locking in the
> kdevelop application?

We have separate locks within kdevelop for kdevelop-related code, but to 
interact with the KTE interfaces from the non-main thread, locking is 
required.

> I think still, there a lots of hidden deadlocks and errors in katepart's
> locking and no app beside kdevelop needs this.

I'm not sure if that's true, but if so, only kdevelop will encounter these 
deadlocks then, because katepart's use of locks within a single thread only 
will not cause any bug (ie. if you don't use the smart lock from another 
thread, it's not possible to cause a deadlock).

> It would be really cool, if it could be removed in the KDE 4.4 timeframe.

What is the alternative?

Cheers,
Hamish.

_______________________________________________
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
[prev in list] [next in list] [prev in thread] [next in thread]