Thread-safety issue in cmake support ?

[David Nolden]

That is ugly (IMO) and complicated though, because you need a lot of changes
to the codebase, and whenever you want to use something from within the
background thread you have to thing hard how to get it there. It's much
simpler to simply introduce a big lock through which you can access
anything, and then make sure it's used seldomly enough and only for short
intervals to make sure there is a minimum amount of lock contention.

It wouldn't even be desirable to eliminate all instances of the lock, as the
lock would achieve the same as a message-passing interface between the
foreground and background which would be the alternative, just with much
less code.

I'm pretty sure that only very few instances of the big lock would cause
performance issues. We can identify those instances and think out something
better there, but for most usecases the foreground lock should work
perfectly, because (at least in c++ support), access to foreground data is
only needed in few cases.

Greetings, David

Am 09.06.2010 13:09 schrieb "Esben Mose Hansen" <kde at mosehansen.dk>:

On Wednesday 09 June 2010 08:23:53 Christoph Cullmann wrote:
> You must first pack all stuff needed ...

> For the kate part case that means, getting text and revision number, doing
> all parsing on the co...
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?

--
kind regards, Esben


-- 
KDevelop-devel mailing list
KDevelop-devel at kdevelop.org
https://barney.cs.uni-potsdam.de/mailma...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100611/18b578ae/attachment.html>