[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
report at bugs.python.org
Sun Feb 13 16:34:19 CET 2011
Pauli Virtanen <pav at iki.fi> added the comment:
Ok, good, that diversion was then avoided :)
So, am I on the right track that there would not be many objections to clarifying the docs of Py_buffer spec by stating:
- For each buffer yielded by `bf_getbuffer`, `bf_releasebuffer`
is called exactly once.
Each `bf_releasebuffer` call is guaranteed to get the same
view->internal pointer as filled in previously by the
All other fields in `Py_buffer` may be modified by the consumer,
and `bf_releasebuffer` may not assume they contain valid data.
- The exporter of the buffer must ensure that apart from the contents
of the memory pointed to by `buf`, the contents of the returned
Py_buffer (format, strides, shape, etc.) remain unchanged.
If the latter is not true, it will lead to no end of trouble in e.g. multithreaded programs.
What about the more strict requirement:
- `bf_releasebuffer` is guaranteed that all fields except `obj`
are not modified?
This could simplify implementation of exporters, and I suspect that MemoryViewObject is a special case, as most consumers probably would not want to make such modifications.
I can try preparing an updated patch based on some combination of the above, taking into account your comments.
BTW, should I take this discussion to Python-dev? So far, I kept it here, as this bug report seemed to be about general issues in the current implementation and spec.
Python tracker <report at bugs.python.org>
More information about the Python-bugs-list