Antoine Pitrou <pit...@free.fr> added the comment: 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) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9602> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
