Greg Ewing wrote: > 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.
That's why I was initially proposing to pass in the original Py_buffer when requesting a lock. > 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. I agree, especially since I expect read-only buffers to be quite common. Locking can always be done in Python space. That may require a Python function call and may thus be less efficient, but locking semantics can be pretty diverse and correctness is usually more important than absolute speed here. So I wouldn't mind leaving the locking business entirely to a separate protocol between providers and consumers, maybe with a short note in the PEP that the API of the provider should follow the locking API in the threading module as far as appropriate. One question: what does that mean for the mutable bytearray class? How would that handle locking? 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
