From: Ulrich Hertlein <[email protected]>
To: osg-users <[email protected]>
Subject: [osg-users] osg::ref_ptr thread safety
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
try m_resource.release().
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi guys,
during a recent discussion at the office the question was raised whether or not
there's
anything architectural that's stopping the owner of a ref-counted resource to
return it
via a raw pointer and dereference (and hence delete it) before it's assigned to
a
receiving ref_ptr.
Along these lines:
caller: Resource* r = foo();
owner: return m_resource.get()
(separate thread does m_resource.reset() or similar)
caller: ref_ptr p(r);
ref_ptr is assigned return value of 'foo()' which is now a dangling pointer.
(Yes, you would usually do 'ref_ptr p(foo())' but that's not fundamentally
different
from the above sequence.)
To the best of my knowledge there's nothing in the design of ref_ptr that stops
this,
but then again I don't believe it's an issue because otherwise we'd surely have
heard.
Can anyone think of something (in the ABI, or elsewhere) that would prevent
this?
Cheers,
/ulrich
------------------
Failure is the mother of success.
Wu Zhicheng
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
