question about AbstractFileManagerPluginPrivate::eventuallyReadFolder()
mail at svenbrauch.de
Sat Oct 7 09:37:24 UTC 2017
On 07/10/17 11:27, René J. V. Bertin wrote:
> QObject::thread() returns "the thread in which the object lives." That's a
> little vague but that means " the thread in which the object was created", no?
> In this case that would cause a DirectConnection to be used, which supposedly
> isn't right for signals sent from another thread.
The thread the object lives in is the thread it is created in, until it
is moved _from that thread_ to another thread with moveToThread().
> The issue is reproducible (only the project toplevel directory is loaded when
> using Qt::QueuedConnection explicitly). It turns out though that the finished and
> entries signals are sent from code that appears to be running on the thread that
> created the FileManagerListJob instance. That explains why a DirectConnection is
> safe (but not why a QueuedConnection isn't?)
I didn't look in this case, but a thread is not necessarily running (and
actually executing) an event loop. That is required for queued signals.
> @Sven: didn't you remark that the project also imports the build directory? I
> saw that happen printing the payload of the entries signals. I guess we could
> apply the project filter in addJobItems(), no?
I think something along these lines would help, yes.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the KDevelop-devel