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 kermode, loewis, mark.dickinson, ncoghlan, pitrou, pv, rupole, teoliphant
Date 2011-02-13.19:08:42
SpamBayes Score 1.1551038e-11
Marked as misclassified No
Message-id <1297624124.35.0.201623748108.issue10181@psf.upfronthosting.co.za>
In-reply-to
Content
Ok, here's a patch with some suggested documentation changes + the minimal changes in memoryview to make bf_releasebuffer behave as advertised. Probably shouldn't be applied as-is, though.

Problems remain. Suppose `bf_getbuffer` for memoryview is implemented so that it returns a view exported by the original object (and not the memoryview). Consider an example:

    >>> obj = PictureSet()       # exposes a buffer, say, to "pic_1"
    >>> a = memoryview(obj)      # points to pic_1

Here, `a` grabs a lock to pic_1.

    >>> obj.choose_picture(2)    # switches the exposed buffer to pic_2
    >>> b = memoryview(obj)      # points to pic_2
    >>> c = memoryview(a)

Here, PyObject_GetBuffer in bf_getbuffer for `a` grabs a lock to pic_2 and passes it on to `c`. The spec specifies no ways to get additional locks on pic_1.

    >>> a.release()

Now lock on pic_1 is released, and the buffer may be freed (also, if the handling of shape/stride arrays in memoryview is as it is now, also those are invalidated). One of the two is now true: `memoryview(a)` does not always describe the same area of memory as `a`, OR, `c` ends up with a lock on the wrong area of memory and the program hits a SEGV. 

[clip]
> >   In a sense, this would be more in line with the PEP:
> >   the PyMemoryViewObject would here act as an ordinary object
> >   exporting some block of memory, and not do any magic tricks.
> 
> Well, that sounds wrong to me. The memoryview doesn't export 
> anything; the original object does.

Having the memoryview "own" the exported buffer would be a simple solution to the above issue.

The alternative would be to adjust the spec so that the above type of behavior is forbidden (any buffers and the shape/stride arrays ever exported must remain valid until the last one is released). Not sure if it makes sense to do this if the only gain is a simplification in the implementation of memoryview.

> > It would guarantee that the buffers it has "exported" stay valid.
>
> How would it, since it doesn't know the original object's semantics?

The original object must guarantee that the buffers remain valid until released, as specified in the PEP. Of course, this requires that memoryview counts how many buffers it has exported, and allows release() only if the count is zero.
History
Date User Action Args
2011-02-13 19:08:45pvsetrecipients: + pv, loewis, teoliphant, mark.dickinson, ncoghlan, rupole, kermode, pitrou
2011-02-13 19:08:44pvsetmessageid: <1297624124.35.0.201623748108.issue10181@psf.upfronthosting.co.za>
2011-02-13 19:08:43pvlinkissue10181 messages
2011-02-13 19:08:43pvcreate