Hello, I'm working on a project using QT and boost and we have a requirements that certains signals should be handled inside main QT thread but raised in another thread. So i'm trying approach in the attached file. Basically i've created a SlotFuction which derives from boost::function and does inter-thread magic when needed. I'm not really (yet) boost guru so i would like to have some feedback. It is evident that this approach suffer of one problem: the event handler registration/invocation is not really thread safe, but i think this can be handled automatically by recent thread_safe_signals library. Thanks Vadim
Vadim Lebedev schrieb:
I'm working on a project using QT and boost and we have a requirements that certains signals should be handled inside main QT thread but raised in another thread.
Why don't you use QThread? It hast this functionality (since QT 4.0 (iirc)). Raymond
Raymond Haeb wrote:
Vadim Lebedev schrieb:
I'm working on a project using QT and boost and we have a requirements that certains signals should be handled inside main QT thread but raised in another thread.
Why don't you use QThread? It hast this functionality (since QT 4.0 (iirc)).
Raymond, The components declaring sugnals, have a requirement not to use QT... They should be portable to the plateforms where QT is not available. Thanks Vadim
Vadim Lebedev wrote:
Raymond Haeb wrote:
Vadim Lebedev schrieb:
I'm working on a project using QT and boost and we have a requirements that certains signals should be handled inside main QT thread but raised in another thread.
Why don't you use QThread? It hast this functionality (since QT 4.0 (iirc)).
Raymond,
The components declaring sugnals, have a requirement not to use QT... They should be portable to the plateforms where QT is not available.
The main thread in all the gui toolkits I'm familiar with is running an event-loop. The standard way of having work done in this thread is to send it events. As I see it your signal-framework needs to wrap a toolkit specific way of transporting your signal as an event. In Qt-4 that is directly supported by Qt's signal-slot framework. In Qt-3 you have to use QApplication::postEvent() (only thread-safe method, as far as I recall) and send a QCustomEvent-specialization to some dispatcher object. Regards, Thomas
Thomas Sondergaard wrote:
Vadim Lebedev wrote:
Raymond Haeb wrote:
Vadim Lebedev schrieb:
I'm working on a project using QT and boost and we have a requirements that certains signals should be handled inside main QT thread but raised in another thread.
Why don't you use QThread? It hast this functionality (since QT 4.0 (iirc)).
Raymond,
The components declaring sugnals, have a requirement not to use QT... They should be portable to the plateforms where QT is not available.
The main thread in all the gui toolkits I'm familiar with is running an event-loop. The standard way of having work done in this thread is to send it events. As I see it your signal-framework needs to wrap a toolkit specific way of transporting your signal as an event. In Qt-4 that is directly supported by Qt's signal-slot framework. In Qt-3 you have to use QApplication::postEvent() (only thread-safe method, as far as I recall) and send a QCustomEvent-specialization to some dispatcher object.
Thomas, Im my example the 'mtfunction' template is parametrized by a class which only simulates sending of the message, in real life however, it could be easily replaced by a version which does QApplication::postEvent Thanks Vadim
Regards,
Thomas
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (3)
-
Raymond Haeb -
Thomas Sondergaard -
Vadim Lebedev