<div class="gmail_quote">On Mon, Jun 7, 2010 at 9:28 PM, Andreas Pakulat <span dir="ltr"><<a href="mailto:apaku@gmx.de">apaku@gmx.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">On 07.06.10 19:52:01, Aleix Pol wrote:<br>
> On Mon, Jun 7, 2010 at 7:40 PM, Milian Wolff <<a href="mailto:mail@milianw.de">mail@milianw.de</a>> wrote:<br>
><br>
> > 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<br>
> > 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<br>
> > 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<br>
> > 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,<br>
> > 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>
> > 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<br>
> > in<br>
> > a multi threaded environment...<br>
><br>
</div></div><div class="im">> why can't we just serialize KConfig accesses inside CMake plugin?<br>
<br>
</div>Because its not the only one accessing kconfig. The problem actually<br>
happens mostly when one thread accesses the project config while the<br>
cmake plugin tries to do that too. So the only way to fix that is having<br>
1 global mutex to lock a specific kconfig object (i.e. project config).<br>
This could be done by wrapping KConfig in a custom class that replicates<br>
some of KConfig's API but would mean adjusting all code that uses it and<br>
it would also mean loosing some things from the API (like fetching a<br>
config group and writing to it transparently).<br>
<br>
Andreas<br>
<br>
--<br>
Things will be bright in P.M.  A cop will shine a light in your face.<br>
<font color="#888888"><br>
--<br>
</font><div><div></div><div class="h5">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>
</div></div></blockquote></div><br><div>Well then, I guess that the way to solve that for the moment is to move these KConfig accesses to the project initialization.</div><div>That might speed up a little the parsing too.</div>
<div><br></div><div>Aleix</div>