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

Greg Ewing greg@cosc.canterbury.ac.nz
Tue, 30 Jul 2002 13:42:38 +1200 (NZST)


Guido:

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

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.

Note that there can't be any problems with deadlock,
since no blocking is involved. Maybe "locking" is even
the wrong term -- it's more a form of reference counting.

> 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.

Mind you, if a release call is necessary, whoever holds the
pointer must also hold a reference to the Python object,
so that they can make the release call. So incrementing the
Python refcount might not be necessary after all!

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg@cosc.canterbury.ac.nz	   +--------------------------------------+