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 _______________________________________________ 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
