search

gdtiti / alembic

Automatically exported from code.google.com/p/alembic
0 stars 0 forks source link

Scalar and Array Properties can run into trouble when parented to the top compound of an OObject. #171

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
In my dev branch a test was added to:
/lib/Alembic/AbcCoreHDF5/Tests/ScalarPropertyTests.cpp
named: testPropScoping()

If the Object goes out of scope and the created Scalar or Array Property stays 
in scope writes to those properties will fail as the top compound property will 
have been destroyed by the Object.

Original issue reported on code.google.com by miller.lucas on 4 Jun 2011 at 1:40

GoogleCodeExporter commented 8 years ago 
I  suspect this is also try on the read side. BaseOrImpl.h holds  TopCprImpl * 
m_properties, and if the IObject goes out of scope this top-compound is 
deallocated (it's not a shared pointer). I'm pretty sure we can't use a shared 
pointer here because that would result in a cycle of properties pointers and 
then they would never free... Is it meaningful to allow writes to properties 
when that property's object has been destroyed?  In other words is that big of 
a burden to ask client code to hang onto its object while writing that object's 
property?

Original comment by ble...@gmail.com on 4 Jun 2011 at 2:00

GoogleCodeExporter commented 8 years ago 
It's an unfortunate side effect of keeping parent objects and compounds alive 
while the children are still alive.

This problem only occurs because of the relationship between the Object and 
it's top level compound. To avoid a pointer cycle like you mentioned.

The schema compound (parented to the top level) doesn't have this issue and any 
scalar or array properties parented to any descendants of top level won't have 
this problem.

Original comment by miller.lucas on 22 Jun 2011 at 10:48

GoogleCodeExporter commented 8 years ago 
OK, I had brought over your change to ScalarPropertyTests.cpp that tested for 
this, but I'll revert it.

Original comment by ard...@gmail.com on 23 Jun 2011 at 12:04

GoogleCodeExporter commented 8 years ago 
Necroing this one, I've run into this again while looking into some performance 
improvements.

This time I believe I've found a solution.

Original comment by miller.lucas on 10 Mar 2012 at 1:54

GoogleCodeExporter commented 8 years ago 
The write side solution (among other things) can be found here:

http://code.google.com/r/millerlucas-dev/source/detail?r=b694471b4c24cec6474974c
e3de0c310646e2f4c

Relevant files are:
CpwData.h/cpp CpwImpl.h/cpp OwData.h/cpp, OwImpl.h/cpp

Original comment by miller.lucas on 10 Mar 2012 at 2:32

GoogleCodeExporter commented 8 years ago 
Write and read side have been done for a while.

Original comment by miller.lucas on 17 May 2012 at 6:17

GoogleCodeExporter commented 8 years ago 
Fixed in the new released 1.1

Original comment by miller.lucas on 2 Aug 2012 at 11:11