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