Thread-safety issue in cmake support ?

Christoph Cullmann cullmann at absint.de
Wed Jun 9 16:12:47 UTC 2010


On Wednesday 09 June 2010 14:12:00 Andreas Pakulat wrote:
> On 09.06.10 13:06:50, Esben Mose Hansen wrote:
> > On Wednesday 09 June 2010 08:23:53 Christoph Cullmann wrote:
> > > You must first pack all stuff needed for your thread into a local copy,
> > > then start it working only on that copy of the data and only do
> > > feedback via a well defined interface, for example some queued signals
> > > at the very end. For the KConfig case, that means collecting the
> > > needed config values once before the parsing thread does its work. It
> > > makes no sense to allow changing config while it is running anyway,
> > > then you can abort and restart the parsing in any case.
> > > For the kate part case that means, getting text and revision number,
> > > doing all parsing on the copy and create dumb ranges in the thread,
> > > after done, creating + translating the moving ranges in the main
> > > thread.
> > 
> > Thank you for doing my todo-list for me :) This is exactly what we need
> > to migrate towards. That is, we need a rule that once a thread is
> > spawned, it is only allowed to access its own data. Yes, it will be a
> > long time before that is totally true, but every time a thread job does
> > this KDevelop will be a little more stable.
> > 
> > Surely, working towards this is not impossible?
> 
> The question is not so much what is possible and what is not, but what is
> realistic to do. I don't know the job-creation enough to know wether its
> possible to implement such a change without rewriting half (or more) of the
> codebase, but such a huge rewrite is probably not going to happen (in
> particular because there's currently nobody with time+knowledge to work on
> language support at all)
Then you are stuck more or less with the BKL idea of David.
I don't see any other solution, than the big lock, if there is no policy in 
place, how to isolate the threads from the gui during their runtime.

The failing smartMutex shows, that even alone locking the kate part properly 
is close to impossible, without really spreading the lock to every function in 
kate part that might be called and then you get the risk of deadlocks.
Same holds for KConfig, and I guess other things, too.

As for KDE 4.6 all locking will be purged in kate part, I guess the best 
chance is to do the BKL. (beside if you fork kate part, but I doubt you really 
want that, given the smart mutex approach does clearly not work and the 
concept of the smart* interfaces as whole are I would say 90% of the crashs we 
have atm, beside some hidden folding problems and asserts in buffer because of 
still sometimes wrong undo/redo, which might be fixed since some weeks)

Greetings
Christoph

-- 
-------------------------------------- Christoph Cullmann ---------
AbsInt Angewandte Informatik GmbH      Email: cullmann at 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




More information about the KDevelop-devel mailing list