[Bf-codereview] Camera tracking integration (issue 5285047)

[g.ulairi at gmail.com]

> > Hrm. In fact problem is not cause by cache size. The only issue i
can see here
> > is that IMB_freeImBuf isn't therad-safe. If we'll add
IMB_freeImBuf_threadsafe
> > function which will just call IMB_freeImBuf from critical section
and switch
> > movie/sequencer to use this function, this stuff would be totally
thread safe.
> > Not sure if there's more simple solutions for this, but don't think
it's
> really
> > critical issue. The same thing can happen with sequencer before my
refactor
> here
> > (aka it's not new issue).

> The threading issue I'm referring to is mostly when you use pixels
from the ibuf
> after getting it, since the cache could free it. I.e. one thread might
get an
> ibuf, another might get a different ibuf, forcing the first ibuf out
of the
> cache and freeing it.

> Anyway, this might not happen in practice in this code so it's a minor
issue. If
> I wrote this code I'd put the locks in the tracking code to indicate
that's it's
> because of the the logic there that this is thread safe, but it's your
choice.

That issue wouldn't happen if thread-safe IMB_freeImBuf function would
be used: cache increments ref count for buffer it returns, and
IMB_freeImBuf destroys actual data only when ref counter is zero,
otherwise it'll just decrease ref count. AFAIR, when buffer gets deleted
fomr cache due to limit, it'll also be just de-referenced instead of
"silent" destroy when going out of cache size limit.

http://codereview.appspot.com/5285047/