Author pitrou
Recipients kermode, loewis, mark.dickinson, ncoghlan, pitrou, pv, rupole, teoliphant
Date 2011-02-13.15:02:14
SpamBayes Score 1.66474e-05
Marked as misclassified No
Message-id <1297609331.3802.36.camel@localhost.localdomain>
In-reply-to <1297607710.96.0.641485698052.issue10181@psf.upfronthosting.co.za>
Content
> > Hmm, there's a misunderstanding. bf_releasebuffer is called exactly
> > once for each call to bf_getbuffer.
> 
> Wrong: http://bugs.python.org/issue7433

This is a different issue.

> static int
> memory_getbuf(PyMemoryViewObject *self, Py_buffer *view, int flags)
> {
>     int res = 0;
>     CHECK_RELEASED_INT(self);
>     if (self->view.obj != NULL)
>         res = PyObject_GetBuffer(self->view.obj, view, flags);
>     if (view)
>         dup_buffer(view, &self->view);
>     return res;
> }
> 
> After this, PyBuffer_Release will be called twice: once on the data in
> *view, by whoever acquired the buffer from memoryview
> , and once on self->view, by memory_dealloc.

PyObject_GetBuffer() is called twice too: once when creating the
memoryview, once when calling memory_getbuf.
So again, bf_getbuffer is called the same number of times as
bf_releasebuffer.

> Note that the view.internal pointer is also clobbered above.

Are you sure? memoryobject.c doesn't touch that pointer at all.

> > > So, `bf_releasebuffer` cannot be used to release any resources
> > > allocated in `bf_getbuffer`.
> >
> > AFAICT, it can. That's what the "internal" pointer is for.
> 
> Sure, guaranteeing that view->internal pointer is not toyed with would
> also be enough.
> 
> But the documentation should spell out very explicitly what the
> bf_releasebuffer call can rely on.

Yes.
History
Date User Action Args
2011-02-13 15:02:14pitrousetrecipients: + pitrou, loewis, teoliphant, mark.dickinson, ncoghlan, rupole, kermode, pv
2011-02-13 15:02:14pitroulinkissue10181 messages
2011-02-13 15:02:14pitroucreate