[Qt-interest] QObject::moveToThread()

[Eirik Ulvik]

Thanks for you reply.
As I said in my reply to Rainer, I hadn't really thought enough about
this. As you mention it might be a way of hacking this together, but I
will not go down that road.
Guess it's time to roll the sleeves up and dive into the legacy code and
rewrite it.

Again, thanks for you replies.

Eirik

Den 19.04.2010 15:42, skrev Cyril C:
> Le 19/04/2010 15:20, Eirik Ulvik a écrit :
>> I am in the process of makin an application multi-threaded. The
>> application consists of one thread doing physics calculations and
>> another doing graphics.
>>
>> My problem is that as the application does not have a 100% clean
>> separation between the two threads ie. some OpenGL calls are made from
>> the physics thread, the OpenGL context was naturally created from the
>> graphics context. Separating these OpenGL calls out and having them in
>> the graphics thread is non-trivial and I would like to avoid do this.
>>
>> I thought a solution would be to switch processing to the graphics
>> thread for the OpenGL calls and switch back when they are done. In
>> pseudo code:
>>
>> void someFunc()
>> {
>> moveToThread(graphics_thread);
>> glBlahBlah();
>> moveToThread(physics_thread);
>> }
>>
>> This approach however does not work, the glBlahBlah function executes in
>> the original thread. Doing this on the other hand works:
>>
>> QThread *curr;
>>
>> void someFunc()
>> {
>> curr = QThread::currentThread();
>> moveToThread(graphics_thread);
>> QTimer::singleShot(10, this, doGl());
>>   
> Did you mean "QTimer::singleShot(10, this, SLOT(doGl()));" ?
> Anyhow, why not set the delay to zero ? My understanding is that when
> moveToThread returns, the object has been moved.
> Btw you can then forget about the QTimer and use
> "QMetaObject::invokeMethod(this, "doGl" ,Qt::QueuedConnection)".
> Assuming, of course, doGl is a slot.
> The only remaining problem is that you'd better be sure that there is no
> pending event that targets you QObject when someFunc() is executing,
> otherwise they will probably get processed in the main thread.
> You may want to ensure that by flushing the events with a
> QCoreApplication::sendPostedEvents(this, 0) before the moveToThread() call.
> And anyway, as said by Rainer, when you startg dealing with such
> considerations, it's usually a good time to rethink a bit of your design !
> HTH
>> }
>>
>> void doGl()
>> {
>> glBlahBlah();
>> moveToThread(curr);
>> }
>>
>> Problem is that as this is a realtime application I really cannot use
>> timers in this way to delay execution. I thought of overloading the
>> event slot and handling QEvent::ThreadChange, but this failed as well.
>>
>> I would like to know if anyone has input on this. Have I misunderstood
>> how the moveToThread function works? From the documentation I thought
>> that the first approach should work.
>>
>> Regards,
>> Eirik
>>
>>   
>>
>>
>> _______________________________________________
>> Qt-interest mailing list
>> Qt-interest at trolltech.com
>> http://lists.trolltech.com/mailman/listinfo/qt-interest
>>   
> 
> 
> 
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 551 bytes
Desc: OpenPGP digital signature
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20100419/0b353b46/attachment.bin