setReadArraySampleCachePtr isn't multithread safe about alembic HOT 13 CLOSED

The sample cache is not really useful in any real application and isnt' likely 
going to be fixed.

Lucas, can you elaborate a bit more on that?  Why wouldn't the cache be useful 
in any case ever...?

Technically Brian mentioned this, but I will defend it anyway, since I agree 
with it.

First, he didn't say it wasn't ever useful, it's just not useful in practice, 
here is why:

All of the applications I've dealt with, OpenGL, Maya, Katana, etc, have their 
own internal structures that you need to copy the data into, so you ALWAYS need 
to copy over the data from the ArraySamplePtr into the GLFloat array, 
MFloatArray or whatever.

The plugin developer will want to store this in their applications native cache 
form when available anyway, so if they happened to use Alembics cache and their 
application specific cache, they would be using twice as much memory, this is 
clearly very bad.

The very best way to do reading at the lower levels is to have 3 different 
methods:
1. read just the key (already have)
2. read just the data, but not the key (don't have)
3. read the data and the key (currently happens via the read which gets the 
ArraySamplePtr)

Okay, sorry for the misattribution (I swear I saw your name on it but I see 
Brian's now :)  And thanks for reminding me about the need to copy out to 
internal data structures in many cases.  My gut still says there is a future 
where code could be re-worked to pull or draw directly from the abc stream and 
not copy and the promise of keeping one copy of the geom in memory when drawing 
bazillions of something is still tantalizing, I would hate to see fixing this 
get completely put off.  The original note implied this should just be ignored 
but please let's not.  Not the hottest priority perhaps, but not the lowest 
either.

Thanks,

The problem is that the one copy you want to keep in memory is an application 
specific copy.

Adding to Milestone 1.1

hdf5 internally caches all data access anyway.
If you want more cache, you can simply read about how it works and how to set 
it in the hdf5 documentation here:

http://www.hdfgroup.org/HDF5/doc/H5.user/Caching.html

I'm not sure why you would want to duplicate such functionality in Alembic, 
since it's underlying subsystem (hdf5) already does this perfectly well.

The keys allow you to avoid reading the same data in different HDF5 files.

We aren't duplicating hdf5's caching functionality in Alembic.