Thread-safety issue in cmake support ?

Sandro Andrade sandro.andrade at gmail.com
Mon Jun 7 20:26:39 UTC 2010


On Mon, Jun 7, 2010 at 2:52 PM, Aleix Pol <aleixpol at kde.org> wrote:
> On Mon, Jun 7, 2010 at 7:40 PM, Milian Wolff <mail at milianw.de> wrote:
>>
>> Christoph Cullmann, 07.06.2010:
>> > On Monday 07 June 2010 18:57:27 Milian Wolff wrote:
>> > > Christoph Cullmann, 07.06.2010:
>> > > > On Monday 07 June 2010 18:34:42 Andreas Pakulat wrote:
>> > > > > > Error occurs either in main thread or in plugin. When in main
>> > > > > > thread it raises from
>> > > > > > a slot execution which it turns call a method using
>> > > > > > introspection,
>> > > > > > making things difficult to investigate.
>> > > > > >
>> > > > > > IMHO, a lock in CMakeUtils would be a possible solution.
>> > > > >
>> > > > > Oh, or we could just drop KConfig usage and use QSettings for the
>> > > > > project files. After all we might have to get rid of kcm-usage for
>> > > > > project-config too. The only thing we'd loose is the ability to
>> > > > > read
>> > > > > from two files "at the same time". But then again, maybe its even
>> > > > > good that where stuff is written is more explicit so we can more
>> > > > > easily move things around...
>> > > >
>> > > > QSettings ist not thread-safe, only reentrant.
>> > >
>> > > Making the foreground lock look even better :)
>> >
>> > I can only second then Andreas, you will kill your multi-threading then
>> > completly I guess :/
>> >
>> > Like the name, the BKL (either big kernel or big kdevelop lock), you
>> > will
>> > get lock contention really fast I guess, didn't you already some
>> > profiling
>> > work, showing that atm the lock contention is high?
>> >
>> > I don't know any solution for the locking problems beside the bkl, too,
>> > as
>> > kdevelop just intermixes to much stuff without locking and with the gui,
>> > but keep in mind: each event, each mouse move, anything will trigger the
>> > locking of this lock and compete with all your background threads, which
>> > compete with each other then, too.
>>
>> True, it's a sad world we live in :)
>>
>> If someone has a better idea, I'm all for it though :-) Until then, it's
>> probably the only thing we can do.
>>
>> There are sadly too many tools out there which we must use that do not
>> work in
>> a multi threaded environment...
>> --
>> Milian Wolff
>> mail at milianw.de
>> http://milianw.de
>>
>> --
>> KDevelop-devel mailing list
>> KDevelop-devel at kdevelop.org
>> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>>
>
> why can't we just serialize KConfig accesses inside CMake plugin?

Yes, I also wonder about that ...

Sandro

> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
>




More information about the KDevelop-devel mailing list