Thread-safety issue in cmake support ?
Esben Mose Hansen
esben at ange.dk
Wed Jun 9 08:02:06 UTC 2010
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?
kind regards, Esben
Ange Optimization Aps
More information about the KDevelop-devel