Hi Cory, I think the right thing to do would be use a Qt smart pointer to manage the lifetime of the singleton rather than use ref_ptr/Referenced. I don't know what would be the appropriate one to use on the Qt side though.
Robert. On 15 July 2015 at 17:59, Cory Slep ARA/SED <[email protected]> wrote: > Hello Robert, > > > > Good catch, as Qt will not handle this cleanup automatically as HeartBeat > has no parent that is explicitly deleted. Converting the static type from > HeartBeat* to osg::ref_ptr<HeartBeat> solves the problem when the library > is unloaded or upon program exit. I am not aware of a use case to delete > HeartBeat at any other time, so I believe the smart pointer option is the > path of least resistance. > > > > In the attached file, the changed within are: > > - Everything mentioned previously, > > - #include-ing ref_ptr and Referenced from osg, > > - HeartBeat inherits from osg::Referenced, and > > - static type of heartBeat is now a osg::ref_ptr<HeartBeat> instead of a > HeartBeat*. > > > > Thanks for your time, > > Cory > > > > *From:* osg-submissions [mailto: > [email protected]] *On Behalf Of *Robert > Osfield > *Sent:* Wednesday, July 15, 2015 3:19 AM > *To:* OpenSceneGraph Submissions > *Subject:* Re: [osg-submissions] Minor Bugfix with Qt on Android > > > > Hi Cory, > > Thanks for the explanation of the problem and suggested fix. I had done a > first pass review and would like to get a fix for this in the OSG-3.4 > branch for the next release candidate, however, I feel the submission needs > a bit more clarification/refinement before I can merge. > > The problem I see is that the submission has no obvious means for memory > clean up. Is it possible that Qt will do this for us? Would using a smart > pointer of somekind for the HeartBeat object solve this problem? > > Robert. > > > > On 14 July 2015 at 19:09, Cory Slep ARA/SED <[email protected]> wrote: > > All, > > > > When using Open Scene Graph and Qt on Android, the resulting thread that > an application developer’s Q*Application is run on is different than what > Qt considers the “main” thread, which can cause subtle problems. This is > because Qt loads native libraries in one thread, and later runs the > application in a different thread. They delay running in the second thread > as long as possible as they have a nontrivial bootstrapping process. The > motivation for Qt having this second thread is to allow them to remain > responsive to both Java and native events, and capture events that would > otherwise be “missed”. > > > > This gives arise to the requirement that a static initialization of a > QObject cannot occur for the Android platform, as Qt incorrectly considers > that first thread the “main” one before a client application has even begun > executing in its second thread. > > > > The HeartBeat in GraphicsWindowQt.cpp is a QObject static global > initialized at load time, causing the above issue. This changeset changes > it to be a singleton that is constructed upon first access to its > “instance” method. > > > > I have: > > - added the static method “instance”, > > - moved its constructor to be private, and > > - changed the one place it is accessed to access it through the “instance” > method. > > > > With these changes, it no longer is statically initialized upon library > loading. > > > > I have tested this with our particular application: > > Open Scene Graph Library 3.3.8 > > Samsung Galaxy S5 > > Android API Level: android-19 > > NDK: r10d > > Qt: 5.4 > > > > As of my pull from git today for Open Scene Graph 3.5.0, it still does not > appear to be fixed. > > > > This is my first patch submission; please let me know if anything needs > correction, clarification, or elaboration. > > > > Thanks for your time, > > Cory > > > _______________________________________________ > osg-submissions mailing list > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > > > _______________________________________________ > osg-submissions mailing list > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > >
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
