[Python-3000] patch: bytes object PyBUF_LOCKDATA read-only and immutable support
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
> 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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-3000