Thread-safety issue in cmake support ?

[Milian Wolff]

David Nolden, 11.06.2010:
> 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.

This I don't get. Each SmartRange or well, in future, each MovingRange must be 
accessed in the MainThread since the document might get edited while getting 
parsed.

And to my knowledge lots of ranges get created + ranges set etc. pp. while 
parsing a file that's currently open in the editor, no?

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100611/8c01c1b1/attachment.sig>