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

Greg Ewing greg.ewing at canterbury.ac.nz
Thu Jun 5 03:22:55 CEST 2008


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.

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.

So I propose that it be declared outside the scope of the
buffer protocol altogether. The only form of locking known
to the buffer protocol should be move-locking, which is
implicit in every call to getbuffer. Supporting this
requires at most a simple counter, and if the provider never
moves its memory anyway, it can ignore locking completely.

> This encourages a short-read, short-write use pattern and always requires all
> consumers to call releasebuffer before any write access can be granted. I don't
> know if that scenario is realistic and/or efficient, but it would work and does
> not even require the LOCK flag, the WRITABLE flag would be enough.

It sounds like you're heading towards the same conclusion,
if I understand what you're saying correctly.

-- 
Greg


More information about the Python-3000 mailing list