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.
Thinking about this some more while updating the PEP: This scheme has the advantage of always guaranteeing a consistent buffer state, as no consumer can be granted write access while any other consumer has read access. However, getting exclusive write access is hard, as this requires that there are no reading consumers, including the consumer who wants to get write access. So you'd always have to release your own read buffer before acquiring a write buffer (which also implies that the provider must never deallocate the buffer just because all readers have released their buffer view). 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. Comments? 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
