(original) (raw)
On 9/11/07, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
+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.
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
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