LanguagePlugins and AlwaysOn

[Andreas Pakulat]

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).
 
> 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).

Andreas

-- 
Increased knowledge will help you now.  Have mate's phone bugged.