Stefan Behnel <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> <http://bugs.python.org/issue3046> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
