Stefan Behnel wrote:
Hi,
while implementing Py_buffer support in Cython, I noticed (the hard way,
throught a segfault), that the buffer pointer passed into getbuffer() can be
NULL, e.g. when calling memoryview.tobytes(). According to PEP 3118 (first
paragraph below the getbuffer() signature), this implies setting a lock on the
memory. Funny enough, the LOCK flag wasn't even set in my case, I just get
NULL as buffer and 285 as flags...
The memoryview implementation is not yet done. I'm not sure if that is
the only issue here.
Anyway, my point is that this part of the protocol actually implies setting a
lock on the buffer *provider* rather than the buffer itself, as the buffer
provider cannot distinguish between different buffers based on a NULL pointer
Yes, the language in the PEP could be more clear. Obviously, if you
haven't provided a Py_buffer structure to fill in, then you are only
asking to lock the object's buffer from other access.
Naturally, the exporter should handle the case when no lock is actually
requested.
I know, the protocol is overly complex already and hard to implement from a
provider perspective, and I understand that that was preferred over putting
the complexity into the consumer. But wouldn't it make more sense to *always*
pass the buffer pointer, to let the provider decide what it makes of the
flags?
Perhaps we are not understanding each other. The Py_buffer structure
and the buffer pointer are 2 separate things. It is the Py_buffer
structure than can be NULL when getbuffer is called (the buf member of
the structure is the actual buffer pointer and it is un-defined when
getbuffer is called and it contains the buffer pointer on successful
return).
Thanks for your probing.
-Travis
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
