<br><br><div><span class="gmail_quote">On 9/11/07, <b class="gmail_sendername">Greg Ewing</b> &lt;<a href="mailto:greg.ewing@canterbury.ac.nz">greg.ewing@canterbury.ac.nz</a>&gt; 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>&gt; Any number of concurrent SIMPLE accesses can<br>&gt; 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&#39;s far too vague.
<br>I&#39;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.&nbsp; 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.&nbsp; 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;">&gt; basic read access (I can read, others can read or write)<br>&gt; locked read access (I can read, others can only read)
<br>&gt; basic write access (I can read and write, others can read or write)<br>&gt; exclusive write access (I can read and write, no others can read or write)<br><br>Should that last one perhaps be &quot;I can read and write,
<br>others can only read&quot;?<br><br>Another thread wanting to read but get a stable view<br>of the data will be using &quot;I can read, others can only read&quot;,<br>which will fail because the first one is writing. If the
<br>reading thread doesn&#39;t care about stability, the writing<br>one shouldn&#39;t have to know.<br><br>Then we have two orthogonal things: READ vs WRITE, and<br>SHARED vs EXCLUSIVE (where &#39;exclusive&#39; 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.&nbsp; 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.&nbsp; (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>