Review Request 110211: Make sure assistant actions live in the main thread

[David Nolden]

> On April 27, 2013, 10:29 a.m., David Nolden wrote:
> > Since you create an assistant action for every single problem you encounter in the parser, I rather would recommend you _not_ to create a KAction unconditionally for each assistant action. As I know KDE, a KAction is probably very memory heavy.
> > 
> > I would rather recommend to remove the 'const' from the actions method, explicitly state that the actions should only be created on-demand in that method, and additionally add some assertion somewhere to make sure that the returned actions actually belong to the main thread.
> 
> Sven Brauch wrote:
>     That sounds reasonable. However I would then move the logic of that "create actions the first time actions() is called" to the base class, i.e.
>     * add a (pure?) virtual createActions() method which should create the actions
>     * make actions() non-virtual and non-const, and make it call createActions() the first time it is called
>     Then it's obvious how to implement the interface. What do you think?

Yes that sounds like a good way to do it.


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110211/#review31666
-----------------------------------------------------------


On April 27, 2013, 8:30 a.m., Sven Brauch wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/110211/
> -----------------------------------------------------------
> 
> (Updated April 27, 2013, 8:30 a.m.)
> 
> 
> Review request for KDevelop and Milian Wolff.
> 
> 
> Description
> -------
> 
> When implementing a problem resolution assistant for kdev-python,
> I noticed some very strange behaviour in the assistants API: actions
> would only be executed if they were added to the assistant in the
> actions() method (which is const, and should not create actions!),
> while creating them in the constructor of the assistant made them
> show up, but do nothing when triggered. The root of the problem turned
> out to be that the assistants are instantiated in the parse job,
> thus if you create the actions in the assistant's constructor, they
> will live in the parse job thread, not in the application main thread;
> the KAction's created from the assistant actions however would
> live in the main thread, because the method to convert iAssistantAction
> -> KAction is called from the main thread. Thus, connections wouldn't
> work correctly, as the thread of the receiver is not running an event loop.
> 
> The existing code, as said, smartly™ works around this problem by adding
> the actions to the assistant in the actions() method the first time
> it is called, which happens from the main thread too. This sucks,
> mainly because it cost me two hours to figure out why my actions wouldn't
> be executed when I created them in the constructor, but also because
> the API defines the function as const (which it should be), but the code
> just ignores this (by using const_cast). The real fun thing is that you
> *have* to do non-const things in a function defined by the API as const,
> because there's no other way to make it actually work.
> 
> This patch moves an action to the main window's thread when it is created,
> and also adds an assertion to make sure the connected objects reside
> in the correct threads.
> 
> I'm not very well-informed about Qt's threading stuff (or any threading
> stuff, really) yet, so this might well be the wrong approach to fix the
> issue. If it is, please let me know and suggest a better alternative.
> 
> I see one possible issue: When creating the actions in the constructor, way
> more actions than before will be created, increasing memory usage.
> This might be relevant or not, I don't know, it's probably not; but
> maybe someone can comment on that when reviewing.
> 
> 
> Diffs
> -----
> 
>   interfaces/iassistant.cpp a102f27 
> 
> Diff: http://git.reviewboard.kde.org/r/110211/diff/
> 
> 
> Testing
> -------
> 
> The natural way (adding actions in the constructor) now works. Before I push this, I will refactor the code in cppsupport to create its actions in the constructor, too, instead of this const_cast mess which is currently there.
> 
> 
> Thanks,
> 
> Sven Brauch
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20130427/8267115b/attachment-0001.html>