I have to provide a "linear" scripting interface that runs infinitely next to the GUI, which would block my eventloop. So I am running a QScriptEngine in a seperate thread (beeing aware of the consequences). There is one thing that keeps me puzzled: Usually using multiple threads the communication is safe as long as you use signals and slots, passing objects by value and connecting with Qt::QueuedConnection, right?
So now I want to call a slot of an object which I made available within the scriptengine. The Documentation states:

Emitting Signals from Scripts

To emit a signal from script code, you simply invoke the signal function, passing the relevant arguments:

Qt Code: 
  1. myQObject.somethingChanged("hello");
To copy to clipboard, switch view to plain text mode 
It is currently not possible to define a new signal in a script; i.e., all signals must be defined by C++ classes.
But in the Debugger I can see, that the calls are executed on the scriptengine thread instead of the object's owner thread. I found the workaround by calling
Qt Code: 
  1. QMetaObject::invokeMethod(object,"slotname",Qt::QueuedConnection)
To copy to clipboard, switch view to plain text mode 
in the slot, but i don't want to modify all objects i want to make accessible from within the scriptengine.
Is there a way to force the scriptengine to use QueuedConnection for calling slots?

I have also tried setProcessEventsInterval() for the engine without starting another thread, but couldn't get it to work. Further i don't want the Eventloop to be pumped by the script engine, feels creepy.
Thanks, Lukas