LanguagePlugins and AlwaysOn
zwabel at googlemail.com
Sat Jun 19 11:32:51 UTC 2010
2010/6/19 Andreas Pakulat <apaku at gmx.de>:
> 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.
Yep, of course. It should only change for the existence of the lock.
>> >> 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_, 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?
That would make sense.
More information about the KDevelop-devel