On Wed, Nov 6, 2013 at 11:12 PM, Deniz Koçak <lend...@gmail.com> wrote:
> Hi Jan, > > Thanks for your answer. However, the ambiguous part for me is the > second paragraph of your answer. frame() is being called by the slot > which is connected to timeout() signal of QTimer. As far as I know, > frame() should not return before drawing the drawables with dynamic > data variance and my drawarray is dynamic. Whenever, the user move the > QSlider and fire a valueChanged() signal the data is updated within > the connected slot. This is the part confuse my mind. Both slots are > connected via DirectConnection because all widgets resides in the main > -GUI- thread, which I think cause a synchronous call. Therefore, data > update slot must wait until the frame returns, because of this > mechanism. If this is not true, then I am completely in the wrong > direction. > I believe that DirectConnection is a synchronous call, however that only means that the slot is called right away by the moc generated code and finishes before the function that sent the signal does. Slots connected using the default connection are called only after the code returns to the main event loop where the signal is dispatched eventually. One typically uses the direct connection type with slots where the execution order relative to the function sending the signal is important - e.g. because the function may be doing something later that actually depends on the action that was performed in the slot. However, it doesn't mean that your entire code is synchronized - while the timeout() slot is running you could trigger the other slot that clears the vertex array as well, regardless of the connection type. I don't think that this behaviour is defined in Qt documentation as to which slot gets triggered when relative to the other slots and whether they can run at the same time or not. Especially QTimer could be implemented using a separate thread, thus having your frame() running on the timer thread and the button slot being triggered from the main GUI thread, causing the race you are seeing. If you want to be 100% safe, assume that the slots can be called fully asynchronously from multiple threads (which they actually can) and don't make any assumptions about synchronization between slots, unless you implement it yourself, because there isn't any. There is also some threading inside of the frame() call (e.g. multiple cull visitors running in parallel), but I believe there is a synchronization barrier before returning from that function, so all OSG threads are done before the function returns. Regards, J.
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
