Closed paulmelis closed 5 years ago
We already thought of adding the pendant to ospRelease
: ospRetain(OSPRObject)
.
If you pass the vector of instances in an OSPData
(and keep that around), then the instances should not get released. So it may also be a bug in OSPRay.
Ok, great. I actually haven't tried the extra-OSPData
-trick at this point.
I didn't mean the extra-ospData, but the original one; if that is alive, the instances should be as well (if not, this is a bug).
Ah, misunderstood. I'm indeed keeping it alive for now as a workaround. But it's not optimal, as that data doesn't contain the up-to-date list of instances, only the ones currently being used for rendering, while there are more that are cached until being used again in future.
So you create many Instances, but only a subset of them is used for rendering at a given time? And you did not call ospRelease
on any Instance (currently used or not)? When you put some of those instances in a ospData
, their refcount should increase, and be decreased again when that ospData is released. But then the refcount is still >=1 and the Instances should not get released.
Ok, I checked my code and was indeed inadvertently releasing the initial references in a few places, causing unexpected deleted objects later on
So, can we close this issue? We track the ospRelease()
feature-request independently.
Great! Yes, I'll close it
Currently, incrementing a reference count cannot be done manually. The only user operation on a reference count is to decrease it with
ospRelease
. But when storing references toOSPObject
's (in all their variations) outside of OSPRay's control this becomes quite limiting. For example, I'm storing a list ofOSPInstance
in a regularstd::vector
, which gets updated during program lifetime. At some point that vector gets passed toospNewData
to be used during rendering, but changes are happening to the list at other moments. As the data object might get released outside of my control I cannot guarantee those instance stay alive, other than by storing them in some sort of second "keep-alive"OSPData
object. But when the list changes that object would need to be reconstructed every time, etc. My troubles would be much smaller if I could just have more control over the refcount to match the actual number of references kept.So would it be possible to add an
ospAddReference()
call (or similar name)? And also a way to get the current reference count of an object, e.g.ospGetReferenceCount()
?