Travis Oliphant wrote: > Stefan Behnel wrote: >> 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.
That's what I'm questioning below. > Naturally, the exporter should handle the case when no lock is actually > requested. That would be considered a bug, right? So it should raise an exception? I can't find that in the PEP. >> 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. I know, I wasn't clear, but I actually meant what I said: the buffer pointer may not be without interest. Imagine the case that a provider decides to create more than one buffer, maybe one for read-only access and one for each concurrent request for write access (and then merge the changes back on release). Then creating the lock by passing NULL as Py_buffer would set a lock on the provider object, not the respective write buffer (or even the read-buffer, where no lock is required). That would be hard to handle by the provider. > 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. But that's only for the buffer creation case. A lock request could just pass in the correct buffer and set the LOCK flag. That doesn't even change the single buffer case (where overwriting the buffer pointer with itself does no harm), but it enables the multiple buffer case. Stefan _______________________________________________ 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
