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

[Greg Ewing]

Stefan Behnel wrote:
> I don't think there should always be a lock in the sense that the requestor is
> the only permitted accessor.

No, but there's always a lock in the sense that the provider
is not allowed to move the memory while the buffer is in
use.

As for the other forms of locking, I'm still not sure whether
that's something the buffer protocol ought to be concerning
itself with. It's actually an orthogonal concept -- there's
no logical reason you couldn't hold a read or write lock on
an object *without* holding a move-lock on its buffer the
whole time.

I'm wondering whether it would be better to separate the
two kinds of lock and have a different api for dealing with
read/write locks. Conflating them seems to be making the
buffer api confusing to talk about and complicated for a
provider to implement.

For example, consider a provider whose memory never moves.
If the buffer api confines itself to move-locking, then
that provider can ignore locking altogether. But if locking
can include concepts of read/write access, it has to
maintain state for the lock and handle the logic of managing
it.

Furthermore, the read/write aspect of the lock management
logic is going to be pretty much identical for all buffer
providers, suggesting it ought to be factored out somehow
and implemented in one place.

> Concurrent read access is common and easy to allow.
> Such an "always lock" scheme would disallow long-living
 > buffer references.

But you shouldn't be keeping long-lived buffer references
in the first place.

-- 
Greg