Author pitrou
Recipients kermode, loewis, mark.dickinson, ncoghlan, pitrou, pv, rupole, teoliphant
Date 2011-02-13.19:31:31
SpamBayes Score 2.73948e-13
Marked as misclassified No
Message-id <1297625488.3802.58.camel@localhost.localdomain>
In-reply-to <1297624124.35.0.201623748108.issue10181@psf.upfronthosting.co.za>
Content
> 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

That's a very bad API to begin with. Anyone thinking it is reasonable to
have the concept of a "current element" in a container should write PHP
code instead. If you have individual pictures, please use individual
objects.

>     >>> 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`

So what? c will represent pic_2 anyway, so the behaviour is right. Awful
certainly for the user, but that's because PictureSet implements a
braindead API.

> , 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. 

This all points to completely broken logic in the imaginary PictureSet
class. If someone doesn't get their semantics right, it is not the
buffer API's problem. bf_getbuffer and bf_releasebuffer must implement
symmetric operations; perhaps that's not explicitly worded, but it seems
quite obvious to me.

> 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).

Why would you adjust the spec? This just stems from common sense.
If you provide a pointer to a consuming API, you have to ensure the
pointer remains valid as long as the consuming API is using that
pointer. Actually, that's *exactly* why there's a bf_releasebuffer
method at all.
History
Date User Action Args
2011-02-13 19:31:32pitrousetrecipients: + pitrou, loewis, teoliphant, mark.dickinson, ncoghlan, rupole, kermode, pv
2011-02-13 19:31:31pitroulinkissue10181 messages
2011-02-13 19:31:31pitroucreate