I have a large amount of exported C++ QObject service (ServiceA) exported into multiple QtConcurrent threads which each contain a QScriptEngine.
The engines all execute different script code and the lifetime of the script exists until i terminate the QEventLoop which is running in the same thread the QScriptEngine was created.

The problem i'm randomly running into is that the scripts will call connect on an exposed C++ object and set the receiver as a function in the script, however I can sometimes get segmentation faults coming out of the EventLoop (way down in the call in the ScriptEngine for QMetaObject invokeMethod where a Q_ASSERT(slot && slot.isObject()) will fail. _ServiceA is running in another thread yet exposed to the engine, Example script code:
Qt Code:
  1. Action.execute = function()
  2. {
  3. ....
  4. _ServiceA.notifyCommandComplete.connect(Action.handleCommandComplete);
  5. ...
  6. }
  7. Action.handleCommandComplete = function(commandId)
  8. {
  9. if(commandId == Action.waitingCommandId)
  10. {
  11. _ServiceA.notifyCommandComplete.disconnect(Action.handleCommandComplete); // unregister from the service
  12. ...
  13. }
  14. }
To copy to clipboard, switch view to plain text mode 

C++ Side
Qt Code:
  1. //This is executed as a QtConcurrent::run function
  2. QEventLoop eventLoop;
  3. connect( this, SIGNAL(signal_actionComplete()), &eventLoop, SLOT(quit()));
  4. if(Invoke()) //Invoke is a call to engine.call("Action.execute") from same thread.
  5. {
  6. eventLoop.exec();
  7. }
  8. disconnect(this, SIGNAL(signal_actionComplete()), &eventLoop, SLOT(quit()));
To copy to clipboard, switch view to plain text mode 

_ServiceA can signal notifyCommandComplete at any time and multiple times asynchroniously so I'm thinking that my QScriptEngine may be evaluating when the slot is invoked and causing a cross-thread access problem (How exactly does QScriptEngine prevent script slots from executing while evaluating?)

This code works 99% of the time so it is definetly some race condition going on with the QueuedConnection events. Theoretically the Action.handleComandComplete should always exist so i'm not sure how the assert would fail in that case? I'm wondering if converting all of my signals (alot of them) to BlockingQueuedConnection may fix the problem but it also leaves the case of QScriptEngine signal disconnection kind of open (how can i guarantee the disconnect occured and voided any incoming events)?