Le mardi 28 septembre 2010 à 03:11 +0000, Lenard Lindstrom a écrit :
> 
> Let's consider Pygame, and the SDL surface it wraps as a
> pygame.Surface. Pygame exposes a surface's data through the buffer
> protocol for manipulation by a NumPy array. Now some SDL surfaces need
> locking before accessing, so Pygame will lock the surface for the
> lifetime of the consumer array. How is the surface unlocked when the
> array is reclaimed? By a buffer proxy that is owned by the array. The
> proxy unlocks the surface when the proxy is garbage collected. The new
> buffer protocol suggests a simpler way, equivalent to contexts, but
> only if the buffer release mechanism works as advertised. This promise
> is broken when a consumer calls PyBuffer_Release before it is done
> with the buffer.

I don't know why you're saying that. The purpose of PyBuffer_Release is
precisely to solve these kinds of use cases (where you want timely
release of a resource rather than rely on the garbage collector).

(you shouldn't even need a proxy anymore; just make the surface object
expose the buffer API, with bf_getbuffer() acquiring the lock and
bf_releasebuffer() releasing the lock. If you want to support several
buffer exports at once, just maintain some internal count of them)