This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author martin.panter
Recipients Arfrever, BreamoreBoy, christian.heimes, jcea, martin.panter, sbt, skrah
Date 2016-04-12.13:12:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1460466766.45.0.764792073138.issue15994@psf.upfronthosting.co.za>
In-reply-to
Content
I recently created Issue 26720 about a similar situation with BufferedWriter. However I am starting to believe that the problem cannot be solved the way I originally wanted. Instead, the best solution there would be similar what I would suggest here: we need to avoid the user accessing the memoryview after readinto() or write() has returned. Some ideas, not all perfect:

1. Call memoryview.release() after the method returns. This would be simple and practical, but could be cheated by making a second memoryview of the original. Also, memoryview.release() is not guaranteed to succeed; there is code that raises BufferError("memoryview has exported buffers").

2. Raise an exception (BufferError or RuntimeError?) if readinto() or write() returns and the memoryview(s) are not all released. This doesn’t prevent a determined programmer from overwriting memory or losing written data, but it might let them know about the problem when it happens.

3. Try to force the memoryview.release() state on all views into the original memory. Is this practical? I guess this would be a bit inconsistent if some other thread was in the middle of a system call using the buffer at the time that we want to do the release.
History
Date User Action Args
2016-04-12 13:12:46martin.pantersetrecipients: + martin.panter, jcea, christian.heimes, Arfrever, skrah, BreamoreBoy, sbt
2016-04-12 13:12:46martin.pantersetmessageid: <1460466766.45.0.764792073138.issue15994@psf.upfronthosting.co.za>
2016-04-12 13:12:46martin.panterlinkissue15994 messages
2016-04-12 13:12:45martin.pantercreate