LanguagePlugins and AlwaysOn

[Andreas Pakulat]

On 19.06.10 11:38:30, David Nolden wrote:
> 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.

And change the affinity back to whatever thread it was after the lock is
released, no? After all an object that wants to call some GUI function may
continue after calling that function in the background. 
 
> >> 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.

You misunderstood what I was trying to say. I was merely saying that a way
for a background thread to schedule some gui operation (in particular one
that it doesn't need to wait upon, i.e. just updating a view or something)
would be something nice to have in the platform. I wasn't suggesting to use
this for this particular use-case (of loading a language plugin from the
background thread).

Hmm, as I still want to progress on the split of core and ui code (and
plugins), this would've helped here too. The cpp language plugin would then
actually be 2 plugins, one that has all the non-gui language-support in it
(like parsing, duchain-building) and the other has the gui actions. The
non-gui one could simply always be loaded and the second one only when a
C++ file is being opened in the editor... What do you think?

Andreas

-- 
Your supervisor is thinking about you.