Message95964
| Author |
pitrou |
| Recipients |
pitrou, pv |
| Date |
2009年12月04日.14:05:02 |
| SpamBayes Score |
4.9308555e-06 |
| Marked as misclassified |
No |
| Message-id |
<1259935530.3383.13.camel@localhost> |
| In-reply-to |
<1259935002.25.0.606018544398.issue7433@psf.upfronthosting.co.za> |
| Content |
> 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).
Yes, I know it looks very painful to do so. I am not responsible for the
Py_buffer / memorview design, however. Travis Oliphant is, and I hear
he's a member of the Numpy community: you might want to ask him for
advice.
(the general problem is that managing Py_buffers can entail memory
allocations, but Py_buffer is not a PyObject and therefore you can't
take advantage of Python's general object management facilities)
> 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.
Well, those calls still /are/ paired, aren't they?
There is one odd thing which you must be careful about, it is that
*_getbuffer can be called with a NULL Py_buffer pointer. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2009年12月04日 14:05:04 | pitrou | set | recipients:
+ pitrou, pv |
| 2009年12月04日 14:05:03 | pitrou | link | issue7433 messages |
| 2009年12月04日 14:05:02 | pitrou | create |
|