[Python-Dev] pre-PEP: The Safe Buffer Interface
Guido van Rossum
guido@python.org
Tue, 30 Jul 2002 11:37:36 -0400
> > I don't like where this is going. Let's not add locking to the buffer
> > protocol.
>
> Do you still object to it even in the form I proposed in
> my last message? (I.e. no separate "lock" call, locking
> is implicit in the getxxxbuffer calls.)
Yes, I still object. Having to make a call to release a resource with
a function call is extremely error-prone, as we've seen with reference
counting. There are too many cases where some early exit from a piece
of code doesn't make the release call.
> It does make the protocol slightly more complicated to
> use (must remember to make a release call when you're
> finished with the pointer) but it seems like a good
> tradeoff to me for the flexibility gained.
I'm not sure I see the use case. The main data types for which I
expect this will be used would be strings and the new 'bytes' type,
and both have fixed buffers that never move.
> > probably nothing that could possibly invoke the Python interpreter
> > recursively, since that might release the GIL. This would generally
> > mean that calls to Py_DECREF() are unsafe while holding on to a buffer
> > pointer!
>
> That could be fixed by incrementing the Python refcount as
> long as a pointer is held. That could be done even without
> the rest of my locking proposal. Of course, if you do that you
> need a matching release call, so you might as well implement
> the locking while you're at it.
I think you misunderstand what I wrote. A py_DECREF() for an
*unrelated* object can invoke Python code (if it ends up deleting a
class instance with a __del__ method).
--Guido van Rossum (home page: http://www.python.org/~guido/)