Hi all, I have a general question regarding threads and signals with boost and Qt. I have a DLL communicating with an external device via Ethernet and a main program with a Qt-GUI for controlling the device. The communciation runs in a different thread than the main program. Qt provides signal/slots across threads, but as I understand it, I have to use the QThread library for it to work. In the DLL I use boost signals and slots and the main program also receives boost signals and then emits Qt's signals to update the GUI, etc. The reason to not use Qt in the DLL was to not force other programmers to use Qt if they want to write their own control application for the DLL. However, I am getting in trouble with synchronization of the threads now and the question is: is it possible / recommended / not recommended to mix Qt's thread API with the boost thread API? Qt provides the possibility of "delayed" signals, that is, a posted signal is queued into the event loop of a thread and, thus, serialized. Is that easily possible with boost threads? Any comments appreciated. Best regards, Rainer
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 26 March 2008 14:08 pm, Rainer Thaden wrote:
I have a DLL communicating with an external device via Ethernet and a main program with a Qt-GUI for controlling the device. The communciation runs in a different thread than the main program. Qt provides signal/slots across threads, but as I understand it, I have to use the QThread library for it to work. In the DLL I use boost signals and slots and the main program also receives boost signals and then emits Qt's signals to update the GUI, etc. The reason to not use Qt in the DLL was to not force other programmers to use Qt if they want to write their own control application for the DLL. However, I am getting in trouble with synchronization of the threads now
Are you aware that Boost.Signals is not thread-safe? It sounds like you are accessing a boost::signal from multiple threads. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH6rPR5vihyNWuA4URAoKiAJ9f/VObZfUPTpVvK83d+BxPCg4lQQCgltkb uVYYyAPx++Bf2Gtl3ZzJn+k= =uFjp -----END PGP SIGNATURE-----
Hi Frank,
In the DLL I use boost signals and slots and the main program also receives boost signals and then emits Qt's signals to update the GUI, etc. The reason to not use Qt in the DLL was to not force other programmers to use Qt if they want to write their own control application for the DLL. However, I am getting in trouble with synchronization of the threads now
Are you aware that Boost.Signals is not thread-safe? It sounds like you are accessing a boost::signal from multiple threads.
Thanks for your comment. No, I didn't consider that. Until now, everything worked, but I can not rely on that. So, it may be better to switch to Qt completely. Best regards, Rainer
Am Mittwoch 26 März 2008 22:08:18 schrieb Rainer Thaden:
Hi Frank,
In the DLL I use boost signals and slots and the main program also receives boost signals and then emits Qt's signals to update the GUI, etc. The reason to not use Qt in the DLL was to not force other programmers to use Qt if they want to write their own control application for the DLL. However, I am getting in trouble with synchronization of the threads now
Are you aware that Boost.Signals is not thread-safe? It sounds like you are accessing a boost::signal from multiple threads.
Thanks for your comment. No, I didn't consider that. Until now, everything worked, but I can not rely on that. So, it may be better to switch to Qt completely.
or consider - http://svn.boost.org/trac/boost/browser/sandbox/thread_safe_signals from: Frank Mori Hess :) Best, -- Maik
Hi,
or consider - http://svn.boost.org/trac/boost/browser/sandbox/thread_safe_signals from: Frank Mori Hess :)
Yepp, I also came across that and wondered why Frank didn't recommend that. Anyway, I am busy with changing boost signals to Qt signals and found the first severe limitation: From Qt docs: "If several slots are connected to one signal, the slots will be executed one after the other, in an arbitrary order, when the signal is emitted. " That is, no grouping as in boost signals is possible. That's really a pity. Best regards, Rainer
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 27 March 2008 06:27 am, Rainer Thaden wrote:
or consider - http://svn.boost.org/trac/boost/browser/sandbox/thread_safe_signals from: Frank Mori Hess :)
Yepp, I also came across that and wondered why Frank didn't recommend that.
I was saving my self-promotional plug for the follow-up response, but I got a reference from an objective third party, which is even better. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH66Hj5vihyNWuA4URAglUAJ9mLzXhv5DYTGqXz1gOhQVmqBVzhQCg4IDU H0TGFgWUFZiYBUrurksfvTw= =+dFN -----END PGP SIGNATURE-----
participants (3)
-
Frank Mori Hess -
Maik Beckmann -
Rainer Thaden