Lenard Lindstrom <le...@telus.net> added the comment:

PEP 3118

"""
Rationale

...

3) There is no way for a consumer to tell the buffer-API-exporting object it is 
"finished" with its view of the memory and therefore no way for the exporting 
object to be sure that it is safe to reallocate the pointer to the memory that 
it owns (for example, the array object reallocating its memory after sharing it 
with the buffer object which held the original pointer led to the infamous 
buffer-object problem).
"""


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.

All the questionable buffer api functions use the PyBUF_SIMPLE access flag. So 
I suggest a PyBUF_SIMPLE access request requires a returned buffer to remain 
valid for the lifetime of the exporter, not the Py_buffer view. If an exporter 
cannot honor this request, due to locking requirements for instance, then it 
raises an exception. All other access request flags promise that 
PyBuffer_Release, and therefore bf_releasebuffer, is called only when the 
buffer is released, not before.

----------
nosy: +kermode

_______________________________________
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

Reply via email to