[Python-Dev] pre-PEP: The Safe Buffer Interface

[Guido van Rossum]

> > 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/)