On 9/11/07, Greg Ewing <[EMAIL PROTECTED]> 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
_______________________________________________ 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
