[issue9602] PyObject_AsCharBuffer() should only accept read-only objects

[Lenard Lindstrom]

Lenard Lindstrom <len-l at 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 <report at bugs.python.org>
<http://bugs.python.org/issue9602>
_______________________________________