Stefan Krah added the comment: First of all, the premise "exports > 0" in your example looks wrong to me. The deallocation process for the first view should start precisely when it no longer has any exports.
In fact, the check for "exports > 0" is for the case when memoryview.release() is called from the Python level. Secondly, even if it did happen (show the code path leading to that!), BufferError would be set in memory_clear() and the garbage collector would throw a FatalError, i.e. step 5+ would not be reached. Lastly, I don't find it very diplomatic to use language like "Deallocation scheme for memoryview is complex and unsafe. It crashes with chained memoryviews..." when you don't seem to a test case or a clear concept of how the alleged bug should occur. ---------- resolution: -> not a bug stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25525> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
