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 pv
Recipients pitrou, pv
Date 2009-12-04.13:56:39
SpamBayes Score 0.00018639612
Marked as misclassified No
Message-id <1259935002.25.0.606018544398.issue7433@psf.upfronthosting.co.za>
In-reply-to
Content
> Why do you say that:
> 
> > There is no feasible way the bf_releasebuffer can keep track of how 
> > many calls to it have been made.

I was probably thinking about allocating new temporary arrays for
strides etc. on each *_getbuffer -- if that's done, then manually
keeping track of all the allocated memory seems like a waste of effort
(ie. not feasible).

But yes, if memory allocated for entries in Py_buffer is shared between
all exported buffer views, that sounds better -- for some reason I
didn't think about that... So we'll do it like this in Numpy then.

But still, I take it that the way it currently works is not the intended
behavior? The segmentation faults caused by this came as a bit of a
surprise to me, as the assumption about paired *_getbuffer and
*_releasebuffer calls is very natural.
History
Date User Action Args
2009-12-04 13:56:42pvsetrecipients: + pv, pitrou
2009-12-04 13:56:42pvsetmessageid: <1259935002.25.0.606018544398.issue7433@psf.upfronthosting.co.za>
2009-12-04 13:56:40pvlinkissue7433 messages
2009-12-04 13:56:40pvcreate