[issue3046] Locking should be removed from the new buffer protocol

[Stefan Behnel]

Stefan Behnel <scoder at users.sourceforge.net> added the comment:

As a quick summary of the problems with the current PEP:

1) Many use cases will not require any locking at all, either because
they run single-threaded with a short-read/short-write pattern, or
because they do not write at all.

2) Write locks require exclusive access rights, but there isn't
currently a way to change an existing read lock into a write lock. This
means that to acquire a write lock, all consumers (including the
requester) must first release all read locks before a write lock can be
granted. Therefore, it is not necessary to have such a thing as a read
lock in the first place, as any read request essentially becomes a
read-lock from the POV of a write lock request. And for data integrity
reasons, some kind of write lock must always be applied when writing is
requested, regardless of requesting a lock or not.

3) The requirement in point 2) for releasing all locks before granting a
write lock necessitates short-read/short-write access, in which case
locking is of limited usefulness already.

4) More complex locking scenarios may also require special locking
semantics that are not currently handled by the proposed locking protocol.

The proposal is therefore to

a) remove the locking protocol all-together
b) leave it to application space how read/write locking should be
handled (if required at all).
c) leave it to providers how a request for a writable buffer should be
handled: by just granting it (thus jeopardising data integrity), by
applying a lock internally, or by copying buffers.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3046>
_______________________________________