[Python-3000] Single buffer implied in new buffer protocol?

[Stefan Behnel]

Greg Ewing wrote:
> Stefan Behnel wrote:
>> So you'd always have to release your own read buffer before acquiring a
>> write buffer
> 
> Yes, you really want to be able to upgrade your own lock
> from a read lock to a write lock, which means the provider
> has to keep track of who the lock holder is somehow.

That's why I was initially proposing to pass in the original Py_buffer when
requesting a lock.


> The more I think about this, the more I feel that implementing
> this form of locking is far too big a burden to place on every
> buffer provider.

I agree, especially since I expect read-only buffers to be quite common.

Locking can always be done in Python space. That may require a Python function
call and may thus be less efficient, but locking semantics can be pretty
diverse and correctness is usually more important than absolute speed here. So
I wouldn't mind leaving the locking business entirely to a separate protocol
between providers and consumers, maybe with a short note in the PEP that the
API of the provider should follow the locking API in the threading module as
far as appropriate.

One question: what does that mean for the mutable bytearray class? How would
that handle locking?

Stefan