[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)

[Antoine Pitrou]

Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine is wanting to make release() nondeterministic by having the
> underlying buffer only released when all views using it either have
> release() called or are no longer referenced.

That's not "nondeterministic" if everyone calls release(). Less so than
garbage collection anyway.

> I contend that release() needs to mean "release the underlying memory
> *right now*" or it is completely pointless. The "I don't want to care
> about lifecycle issues" approach is already handled quite adequately
> by the ordinary refcounting semantics.

Well, if you assume refcounting and no reference cycles, then release()
is AFAICT already useless. See issue9757 for the argument we had with
Guido ;)

My issue is that until now sliced memoryviews are independent objects
and are not affected by the releasing of the original memoryview. With
this patch, they are, and that's why I'm advocating for a subtler
approach (which would really mirror the current slicing semantics, and
wouldn't break compatibility ;)).

release() is supposed to mean "you can dispose of this memoryview", not
"you can dispose of any underlying memory area, even if there's some
sharing that I as an user don't know anything about" (*). By making
release() affect "related" memoryviews we are exposing an internal
implementation detail (the PyManagedBuffer sharing) as part of the API.

(*) for something similar, if you close() a file-like object obtained
through socket.makefile(), it doesn't close the underlying fd until all
other file-like objects are closed too

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________