LanguagePlugins and AlwaysOn

[David Nolden]

2010/6/18 Andreas Pakulat <apaku at gmx.de>:
> On 17.06.10 22:21:19, David Nolden wrote:
>> Simply use the foreground lock. It's the same as andreas's "queue approach,
>> but only with 1 LOC.
>
> Hmm, but then you'd have to remove the explicit check in
> languagecontroller. And yes, I actually thought about suggesting that, but
> wasn't sure wether its in the code already again...
>
> Are you sure loading a plugin works from a background thread? i.e. are the
> kdelibs API's able to do that? Hmm, at least the plugins thread affinity
> should be the main thread as that is (AFAIK) set by the parent QObject
> which is the Core object (that lives in the main thread).

I think the only problem would be the thread affinity. This seems to
be a general problem with the foreground lock. Maybe I can find a way
for the foreground lock to change the thread affinity of created
objects to the foreground, because an equality "have foreground lock
<=> is in foreground thread" would be very desirable.

>> We can then change the check in languageForUrl to VERIFY_FOREGROUND_LOCKED ,
>> and have one less ugly multi-threading problem. I also always thought that
>> it sucks not being able to load plugins from the background.
>
> Yeah, but I still think it would make sense to have a simple abstract KJob
> subclass which executes its "run" method in the main thread. I do
> understand that you have use-cases in the language plugin where this is too
> much overhead, but my experience writing an IDE based on Eclipse shows that
> there are also tons of things where you can actually calculate all data in
> a background thread and then hand it over to a job that runs in the gui. In
> particular things that update the gui state (and not doing so every 10 ms).

But when you call languageForUrl, then it means that you want the
language _now_ plugin, so you will have to wait until the foreground
is ready loading it anyway. That means that we also have to introduce
some kind of locking, aka. "wait until the foreground has loaded the
plugin", and if the background has some resource locked that the
foreground might request during that waiting, we'll have a deadlock as
well, so it will even have the same _disadvantages_ as the foreground
lock. However for the foreground lock we can define some rules and
even add some assertions to make sure that for example the duchain
isn't locked when acquiring it, which makes it the more robust
solution.

But of course, the thread affinity problem needs to be solved first.

Greetings, David