simple thread layout question

[mhoover]

Hi,

The lemonade factory where I work has a Qt application that has two command clients to activate lemonade mixing devices with embedded motor command servers.

For some reason the custom class I use to connect to these command servers takes a LONG time. So I decided to do the connecting in a different thread.

In my main app I have code like this:

commandClient = NULL;
command_thread.cmd = commandClient;
command_thread.start();

Then the thread instantiates the command client (the connection happens in the constructor). When it finishes, it emits a connection_finished() signal.

When my app gets this signal it sets it's own pointer to the command client to the one used by the thread:

commandClient = command_thread.commandClient;
Then it does the necessary connections on the thread.

My question:

Is this a legitimate way of doing threading? It seems to run great. I only do this task once in the background, but my understanding says things can get hairy if different threads exchange objects.

When I quit the GUI I try to delete the commandClient and I get this error:

ASSERT failure in QCoreApplication::sendEvent: "Cannot send events to objects owned by a different thread. Current thread 80f9130. Receiver '' (of type 'LemonadeCmdClient') was created in thread 80f35e8", file kernel/qcoreapplication.cpp, line 289

Then it seg faults. Any ideas?

[wysota]

Make the connection (or better yet, the whole client object) in the run() method of the thread or use QObject::moveToThread to move the client object to the worker thread. Alternatively enforce queued connections.