Message95963
| 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:42 | pv | set | recipients:
+ pv, pitrou |
| 2009年12月04日 13:56:42 | pv | set | messageid: <1259935002.25.0.606018544398.issue7433@psf.upfronthosting.co.za> |
| 2009年12月04日 13:56:40 | pv | link | issue7433 messages |
| 2009年12月04日 13:56:40 | pv | create |
|