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