Question

I have a worker QThread in which a QObject derived object is created. The object is an aggregate of two other QObject derived objects, as such there are internal connections for signal linking and binding the two internal objects together.

The worker QThread is a member of a QPlugin, so is present throughout the lifetime of the plugin.

The problem I have is that although the object is interacting fine with the rest of the application, those internal connections seem to be broken. As an experiment I tried creating the object in the main thread and the internal connections are functioning, so it is definitely something I’m doing wrong with QThreads.

I also tried moving the object back to the main thread (admittedly after those internal connections are made), but it had no effect. I cycled through every type of connection (Direct, Queued, etc) for the internal connections, but it either had no effect or triggered deadlock errors. All the types passed through the connections are registered.

The object is the parent QObject of the two contained objects, it shouldn’t make a difference as they all reside in the same thread, but I tried setting their parent to NULL just to rule it out – it had no effect unsurprisingly. The QThread is not a parent to anything.

The only thing I am not certain of is that the object is created from a factory singleton that resides in the main thread, but is called from the worker thread – so who does it belong to? I am at a complete loss as to what I’m doing (or not doing) to break these connections, so any help is greatly appreciated. Here is the code at the relevant parts of the application:

This the object creation call in the worker thread, for context the object is poly mesh from an OBJ importer.

//  Create mesh.
QString type = Sy::plugMeshType + "Sy_polyMesh";
QString name = proj->newNameIncrement( "objMesh" );

Sy::PluginArgs args; args << name;
Sy_polyMesh* obj = Sy_pluginLoader::createInstance< Sy_polyMesh >( type, args );
obj->mesh() = mesh;
obj->resizeBB();
result_ = obj;

//  If in GUI mode, register it with the project.
if ( gui_ ) {
    proj->registerSimObject( obj );
    proj->selectObject( obj );
}

I have quite an extensive plugin architecture to my app, so the actual thread starting code is abstracted into an abstract worker class:

void Sy_abstractLongProcess::begin( Sy_abstractLongProcessWorker* worker )
{
    worker_ = worker;
    worker_->moveToThread( &thread_ );

    QObject::connect( &thread_, SIGNAL( started() ), worker_, SLOT( work() ) );

    QObject* thisObj = dynamic_cast< QObject* >( this );

    QObject::connect( &thread_, SIGNAL( finished() ), worker_, SIGNAL( finished() ) );
    QObject::connect( worker_, SIGNAL( finished() ), thisObj, SIGNAL( finished() ) );
    QObject::connect( worker_, SIGNAL( progressChanged( double ) ), thisObj, SIGNAL( progressChanged( double ) ) );
    QObject::connect( worker_, SIGNAL( finished() ), &thread_, SLOT( quit() ) );

    thread_.start();
}

As all the relevant code is spread across many classes, I won’t list everything (this question is long enough), but if you need to see anything else don’t hesitate to ask – I need all the help I can get on this one.

Answer 1

I almost had the answer in the original post, when I tried to move the object back to the main thread, only I did it too early. I had to move it back once I completed the modifications that needed to be done in the worker thread – seems obvious now!

Thanks to Mat for putting me on track for working it out