On 9/13/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
> I think if it doesn't go through the buffer interface it is up to the
> object to decide (i.e. what does the object do with itself when buffers
> are exported --- that will depend on the object). All it must do is
> support the buffer in
On 9/13/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Gregory P. Smith wrote:
> > When I read the plain term EXCLUSIVE I read that to mean nobody else can
> > read -or- write, ie: not shared in any sense.
>
> You're right, it's not the best term.
>
> > Lets extend these base
> > concepts to SHARED_RE
Travis E. Oliphant wrote:
> I would want to encourage people not to use the LOCK_FOR_READ unless
> there is an important benefit or need to use it.
If you mean that LOCK_FOR_READ would unilaterally deny
anyone else read access, my proposal avoids this by not
having such a mode at all. So you can
Gregory P. Smith wrote:
> When I read the plain term EXCLUSIVE I read that to mean nobody else can
> read -or- write, ie: not shared in any sense.
You're right, it's not the best term.
> Lets extend these base
> concepts to SHARED_READ, SHARED_WRITE, EXCLUSIVE_READ, EXCLUSIVE_WRITE
EXCLUDE_WRI
Guido van Rossum wrote:
> On 9/11/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
>
>> I'm not sure I understand the difference between a classic read lock and
>> the exclusive write lock concept. Does the classic read-lock just
>> prevent writing to the memory area. In my mind that is a re
That's a different topic altogether. We're talking here about locking
modes for the buffer API (PEP 3118). This does not involve actual
locks -- the operations just fail if the requested lock cannot be
obtained.
On 9/12/07, Joel Bender <[EMAIL PROTECTED]> wrote:
> > Sounds much like the modes offe
> Sounds much like the modes offered by an old operating system that had a
> very nice lock manager.
Awe, VMS isn't THAT old, is it? :-)
I have a wrapper around threading.Lock and threading.RLock that I've
been using that does deadlock detection and have wished for these lock
modes many times
In article
<[EMAIL PROTECTED]>,
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> I guess I would be inclined to propose separate flags for indicating
> the operation that the caller will attempt (read or write) and the
> level of locking (lock the buffer's address or also prevent anyone
> else fr
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.
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 stat
Jim Jewett wrote:
>
> why does it need the lock the whole time?
> Is someone getting known stale data (when you could tell them to
> wait) always OK, but overwriting someone else's change never is?
In a threaded environment, it shouldn't really be
a problem as long as the view of the data is cons
Travis E. Oliphant wrote:
> I'm not sure I understand the difference between a classic read lock and
> the exclusive write lock concept.
A read lock means that others can obtain read locks,
and nobody can obtain a write lock.
A write lock means that nobody else can obtain a
lock of any kind.
I
Guido van Rossum wrote:
> 0 -> 1 -> 2 -> ... (SIMPLE or WRITABLE get)
> ... -> 2 -> 1 -> ... (SIMPLE or WRITABLE release)
> 0 -> -1 (LOCKDATA get)
> -1 -> 0 (LOCKDATA release)
And if this is the correct interpretation, the requests
should be called something like READ_LOCK and WRITE_LOCK
to make
On 9/11/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
> I'm not sure I understand the difference between a classic read lock and
> the exclusive write lock concept. Does the classic read-lock just
> prevent writing to the memory area. In my mind that is a read-only
> memory buffer and the bu
On 9/11/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On 9/10/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
> > Guido van Rossum wrote:
> > > I'd like to see Travis's response to this. It's setting a precedent
> > > regarding locking objects in read-only mode; I haven't found other
> > >
Jim Jewett wrote:
> On 9/11/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
>
>> Guido van Rossum wrote:
>>
>>> ... I'm hoping Travis has a particular way in mind of
>>> handling LOCKDATA that can be used as a template.
>>>
>
>
> Does it do its processing in the original buffer,
Guido van Rossum wrote:
> On 9/10/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
>
>>
>
> Hm, so this is completely different from what I thought. It seems you
> are describing the following:
>
> 1. acquire the buffer with LOCK_DATA
> 2. copy the data out of the buffer into a scratch area
> 3
On 9/10/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I'd like to see Travis's response to this. It's setting a precedent
> > regarding locking objects in read-only mode; I haven't found other
> > examples of objects using LOCKDATA (the only mentions of it seem to
On 9/11/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > ... I'm hoping Travis has a particular way in mind of
> > handling LOCKDATA that can be used as a template.
> The use case I had in mind comes about quite often in NumPy when you
> want to modify the data-area
Guido van Rossum wrote:
> I'd like to see Travis's response to this. It's setting a precedent
> regarding locking objects in read-only mode; I haven't found other
> examples of objects using LOCKDATA (the only mentions of it seem to be
> rejecting it :). I keep getting confused by the two separate
I'd like to see Travis's response to this. It's setting a precedent
regarding locking objects in read-only mode; I haven't found other
examples of objects using LOCKDATA (the only mentions of it seem to be
rejecting it :). I keep getting confused by the two separate lock
counts (and I think in this
A new version is attached; cleaned up and simplified based on your original
comments.
On 8/29/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> That's a huge patch to land so close before a release. I'm not sure I
> like the immutability API -- it won't be useful unless we add a hash
> method, a
I'm inclined to let this one wait for 3.0a2, I'm out of python time for the
week and will be out of town (but online) until next Thursday. Pairing up to
finish it later on would be nice if needed. I'm happy if the immutable
support is dropped, I just figured I'd include it as an example once I
rea
That's a huge patch to land so close before a release. I'm not sure I
like the immutability API -- it won't be useful unless we add a hash
method, and then we have all sorts of difficulties again -- the
distinction between a hashable and an unhashable object should be made
by type, not by value (tu
Attached is what I've come up with so far. Only a single field is
added to the PyBytesObject struct. This adds support to the bytes
object for PyBUF_LOCKDATA buffer API operation. bytes objects can be
marked temporarily read-only for use while the buffer api has handed
them off to something whic
25 matches
Mail list logo
