<br><br><div><span class="gmail_quote">On 9/11/07, <b class="gmail_sendername">Greg Ewing</b> <<a href="mailto:greg.ewing@canterbury.ac.nz">greg.ewing@canterbury.ac.nz</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Guido van Rossum wrote:<br>> Any number of concurrent SIMPLE accesses can<br>> coexist since the clients promise they will only read.<br><br>As a general principle, using a word like SIMPLE in an<br>API is a really bad idea imo, as it's far too vague.
<br>I'm finding it impossible to evaluate the truthfulness<br>of statements like the above in this discussion, because<br>of that.</blockquote><div><br>+1 on that. SIMPLE is a bad name. Based on the pep3118 description, how about calling it 1D_CONTIGUOUS or just RAW or FLAT?
<br></div><br>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.
<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> basic read access (I can read, others can read or write)<br>> locked read access (I can read, others can only read)
<br>> basic write access (I can read and write, others can read or write)<br>> exclusive write access (I can read and write, no others can read or write)<br><br>Should that last one perhaps be "I can read and write,
<br>others can only read"?<br><br>Another thread wanting to read but get a stable view<br>of the data will be using "I can read, others can only read",<br>which will fail because the first one is writing. If the
<br>reading thread doesn't care about stability, the writing<br>one shouldn't have to know.<br><br>Then we have two orthogonal things: READ vs WRITE, and<br>SHARED vs EXCLUSIVE (where 'exclusive' means that others
<br>are excluded from writing).</blockquote><div><br>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:
<br><br>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)<br>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).
<br>SHARED_READ - anyone can read this buffer<br>SHARED_WRITE - anyone can write this buffer<br><br>SIMPLE/FLAT/RAW = SHARED_WRITE | SHARED_READ<br>READ_LOCK = EXCLUSIVE_WRITE | SHARED_READ<br>WRITE_LOCK = EXCLUSIVE_WRITE | EXCLUSIVE_READ
<br></div><br>Just | any of the above with WRIT(E)ABLE if you intend to actually write to the buffer.<br><br>-gps<br><br></div>