[Python-3000] patch: bytes object PyBUF_LOCKDATA read-only and immutable support (original) (raw)

Gregory P. Smith greg at krypto.org
Wed Sep 12 09:44:56 CEST 2007

On 9/11/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:

Guido van Rossum wrote: > Any number of concurrent SIMPLE accesses can > coexist since the clients promise they will only read. As a general principle, using a word like SIMPLE in an API is a really bad idea imo, as it's far too vague. I'm finding it impossible to evaluate the truthfulness of statements like the above in this discussion, because of that.

+1 on that. SIMPLE is a bad name. Based on the pep3118 description, how about calling it 1D_CONTIGUOUS or just RAW or FLAT?

I also like your suggestion of renaming PyBUF api flags to READ_LOCK and WRITE_LOCK as those are well defined concepts in the classic multiple readers or one writer synchronization sense. What I implemented in my bytes patch should really be called PyBUF_READ_LOCK and what Travis describes as LOCKDATA in this email thread should become WRITE_LOCK.

basic read access (I can read, others can read or write) > locked read access (I can read, others can only read) > basic write access (I can read and write, others can read or write) > exclusive write access (I can read and write, no others can read or write)

Should that last one perhaps be "I can read and write, others can only read"? Another thread wanting to read but get a stable view of the data will be using "I can read, others can only read", which will fail because the first one is writing. If the reading thread doesn't care about stability, the writing one shouldn't have to know. Then we have two orthogonal things: READ vs WRITE, and SHARED vs EXCLUSIVE (where 'exclusive' means that others are excluded from writing).

When I read the plain term EXCLUSIVE I read that to mean nobody else can read -or- write, ie: not shared in any sense. Lets extend these base concepts to SHARED_READ, SHARED_WRITE, EXCLUSIVE_READ, EXCLUSIVE_WRITE and use them to define the more others:

EXCLUSIVE_WRITE - no others write to the buffer while this view is open (this does not imply that the requester wants to actually write, thats what the WRIT(E)ABLE flag is for) EXCLUSIVE_READ - no others can read this buffer while this view is open. (this is only useful in conjunction with exclusive write below to make a write_lock). SHARED_READ - anyone can read this buffer SHARED_WRITE - anyone can write this buffer

SIMPLE/FLAT/RAW = SHARED_WRITE | SHARED_READ READ_LOCK = EXCLUSIVE_WRITE | SHARED_READ WRITE_LOCK = EXCLUSIVE_WRITE | EXCLUSIVE_READ

Just | any of the above with WRIT(E)ABLE if you intend to actually write to the buffer.

-gps -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-3000/attachments/20070912/aa420023/attachment.htm

More information about the Python-3000 mailing list