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

[Stefan Behnel]

Hi Greg,

Greg Ewing <greg.ewing <at> canterbury.ac.nz> writes:
> The way I thought this was supposed to work is that the
> buffer is *always* locked while the client is accessing
> it, the only choice being whether it's a read-only or
> read-write lock.

I don't think there should always be a lock in the sense that the requestor is
the only permitted accessor. Concurrent read access is common and easy to allow.
Such an "always lock" scheme would disallow long-living buffer references.


> So the usage sequence is:
> 
> 1) Client calls getbuffer() and receives a buffer
>     pointer. The memory referred to by the pointer
>     is now locked and will not move.

"not move" is just fine, but any locks should be requested explicitly using LOCK
and maybe WRITABLE.


> 2) Client accesses the memory via the returned pointer.
> 
> 3) Client calls releasebuffer(). The memory is now
>     unlocked and the pointer is no longer valid.
> 
> If the client wants to access the buffer again, it
> must go back to step 1.

or if the client wants to acquire a lock that it currently does not hold.

That's pretty much what my locking scheme is proposing, with the difference of
not caring about a possibly valid "buf" pointer being passed into getbuffer
(which I implicitly allow in my proposal anyway).

I like that scheme BTW. It works without an explicit UNLOCK and thus simplifies
my proposal at the cost of a separate Py_buffer allocation for the case of a
postponed LOCK request /after/ requesting the buffer for the first time. And the
Py_buffer allocation will most likely happen on the stack anyway, as a LOCK is
commonly held only during a function call life-time.

I'll fix up the PEP and send another patch ASAP.

Thanks for the feed-back,
Stefan