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.
Cheers, Deniz On Wed, Nov 6, 2013 at 10:19 PM, Jan Ciger <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello Deniz, > > On 11/06/2013 07:07 PM, Deniz Koçak wrote: >> This is already a long mail, still I have more to say, many code to >> post, but I am not sure where should I begin. I can provide as >> much as possible. However, before ending my e-mail, I would like to >> ask if this approach is safe or not? I mean, I call frame() method >> within a Qt slot and again update related datas within another Qt >> slot. Qt has a main loop (GUI thread) of course, and is it possible >> to cause a race-condition with OSG, because it has its own >> threading model? Please ask if you need more information and of >> course you will, I would be glad to tell more. > > Your approach isn't safe. OSG is *not threadsafe*. Or, rather, it is > not threadsafe from arbitrary modifications. If you want to be safe, > the only time when modifications to the scene graph may happen is > before or after the frame() is invoked, not while frame() is running. > > If your GUI is modifying the vertex array from the Qt slot, that is, > by definition, asynchronous - you have no idea when the user presses > that button. Which may well be during the rendering when OSG is using > that data structure. If you are clearing the vertex array while the > size of the array is still set, it will go boom. > > One way to solve this is to use the slot to only modify a buffer/set a > flag and then use e.g. an update callback on the affected OSG node to > pick up the changes and implement them in the scene graph when it is > safe (during update traversal). > > Regards, > > J. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.14 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iD8DBQFSeqRWn11XseNj94gRAuBdAKDuE2rxjaXltXEWg4g2Mka1ZBqVIgCfbKju > vGG9MllrwxlDZjkUd1HHg+8= > =S3At > -----END PGP SIGNATURE----- > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
