Author ncoghlan
Recipients ncoghlan, pitrou, rupole
Date 2010-11-03.12:19:51
SpamBayes Score 3.68424e-09
Marked as misclassified No
Message-id <1288786796.97.0.586977101382.issue10181@psf.upfronthosting.co.za>
In-reply-to
Content
Hmm, if we're ever creating a new copy of a Py_buffer without calling GetBuffer again on the original object, then *that* is a bug (exactly comparable to copying a PyObject pointer without incrementing the reference count - it's OK if you can guarantee the lifecycle of your borrowed pointer is shorter than the lifecycle of the original, but disallowed otherwise).

This still doesn't sound like a problem with the spec to me, it sounds like a problem with the implementation strategy that was originally used when integrating the spec into the interpeter core (which I readily agree received far less attention than the spec itself did).

It really sounds like we should be creating a _Py_ManagedBuffer internal object, with each instance containing a PyObject* and a Py_buffer instance. We don't need to alter PEP 3118 to do that - such a change is entirely consumer side, so the objects providing the buffers don't need to care how the lifecycle of the Py_buffer struct is managed.

When we need another reference to the buffer, we can then just increment the refcount of the _Py_ManagedBuffer instance rather than having to call GetBuffer again on the original object.

The contents of Py_buffer objects that have been passed to GetBuffer really shouldn't be getting modified at all - for those cases, we should maintain *two* Py_buffer structs, one (unmodified) with the original results of the GetBuffer call, and a second owned by the caller (for manipulation).
History
Date User Action Args
2010-11-03 12:19:57ncoghlansetrecipients: + ncoghlan, rupole, pitrou
2010-11-03 12:19:56ncoghlansetmessageid: <1288786796.97.0.586977101382.issue10181@psf.upfronthosting.co.za>
2010-11-03 12:19:54ncoghlanlinkissue10181 messages
2010-11-03 12:19:51ncoghlancreate