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();
commandClient = NULL;
command_thread.cmd = commandClient;
command_thread.start();
To copy to clipboard, switch view to plain text mode
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;
commandClient = command_thread.commandClient;
To copy to clipboard, switch view to plain text mode
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?
Bookmarks