[Moved] new to Qt development
-
wrote on 27 Sept 2011, 14:34 last edited by
I've been doing embedded linux multi- threaded development using pthreads and posix message queues to pass messages. I'm now beginning to use Qt. Do I have to move all of my threading code to Qt. If not how do I send messages from Qt to my linux queues?
-
wrote on 27 Sept 2011, 14:54 last edited by
As you are used to. You can freely mix existing platform-specific code with Qt code (it is C/C++ after all), but you are - of course - not platform independent then.
-
wrote on 28 Sept 2011, 22:51 last edited by
Qt provides signals and slots to send messages between objects. You might have a more easy live if you switch to QThread. I'm not 100% sure if it's possible to use signals/slots with native threads (be sure to force the use of queued connections in this case!)
It is very recommended to read pepps excellent article on "Threads, Events and QObjects":http://developer.qt.nokia.com/wiki/Threads_Events_QObjects in the wiki. It will save you on stepping into common pitfalls using Qt and threads.
-
wrote on 30 Sept 2011, 17:11 last edited by
Can anyone direct me to sample code showing Qt sending messages to native threads?
-
wrote on 30 Sept 2011, 23:06 last edited by
Qt has no means to send messages to native threads. You will have to use the native messaging system the same way as you would without Qt.
-
wrote on 2 Oct 2011, 08:13 last edited by
I guess you could send a Qt signal to a QObject living in a native thread though. And that is basically what you need to do with QThread as well anyway, so it is not that different. Still, I did not try this myself.
-
wrote on 2 Oct 2011, 09:11 last edited by
I'm not really sure if that works with signals and slots, as QThread runs its own Qt event loop and for inter-thread signals you will need queued connections. Do the latter work without an event loop on the receiver side?
-
wrote on 2 Oct 2011, 09:15 last edited by
No, you can not receive signals in a slot from a queued connection without a running eventloop on the receiver (slot) side. But again: that is also the case for QThread-based threads, so no big difference there.
-
wrote on 2 Oct 2011, 09:19 last edited by
True, but with QThread one gets all the infrastructure for thread safe messaging for free. With native threads one cannot use Qt's signal/slots without further means of making them thread safe. IMHO that's a big difference...
-
wrote on 2 Oct 2011, 09:27 last edited by
I'm not so sure about that. I think you can just spin a QEventLoop from any thread, QThread or not. Sure, QThread has it build in, but I don't think there is much magic involved there. Once you have a running eventloop, you can use slots in the thread, right?
I am not saying I'd use this on new code. But if you already have existing threading code that you want to bolt this on to, it should not be impossible to do so.
-
wrote on 2 Oct 2011, 10:49 last edited by
[quote author="Andre" date="1317547623"]I'm not so sure about that. I think you can just spin a QEventLoop from any thread, QThread or not. Sure, QThread has it build in, but I don't think there is much magic involved there. Once you have a running eventloop, you can use slots in the thread, right?[/quote]
Yes, it should be that way. If a QObject class is created inside a thread that is not a QThread (like the main thread) a pseudo QZhread object is created and it works.
6/11