[Python-3000] Single buffer implied in new buffer protocol?
stefan_ml at behnel.de
Wed Jun 4 09:29:27 CEST 2008
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,
More information about the Python-3000