[Python-Dev] PEP 298, final (?) version

[Guido van Rossum]

> > > > >         void PyObject_ReleaseFixedBuffer(PyObject *obj);
> > > > 
> > > > Would it be useful to allow bf_releasefixedbuffer to return an int
> > > > indicating an exception?  For instance, it could raise an exception
> > > > if the extension errantly releases more times than it has acquired
> > > 
> > > The code making the call might not be in an easy position
> > > to deal with an exception -- e.g. an asynchronous I/O
> > > routine called from a signal handler, another thread,
> > > etc.
> > > 
> > > Maybe use the warning mechanism to produce a message?
> > 
> > In an asynch I/O situation, calling PyErr_Warn() is out of the
> > question (it invokes Python code!).
> > 
> > I propose to make it a fatal error -- after all the only reason why
> > bf_releasefixedbuffer could fail should be that the caller makes a
> > mistake.  Since that's a bug in C code, a fatail error is acceptable.
> 
> I don't know if you guys are hinting at the possibility of the
> PyObject_ReleaseFixedBuffer function being called without holding
> the GIL or not, but I think the GIL should be necessary during
> this call.  (As such, the code making the call *could* deal with
> the exception...  even if we don't want it to have to.)

Good point.

> So while a fatal error is still a reasonable response, the 
> asynchronous I/O routine or signal handler or whatever really
> should acquire the GIL before doing the release.  For one thing
> this protects the lock_count variable from race conditions, and
> another, it allows the implementation of bf_releasefixedbuffer
> to use other Python APIs.

Agreed.

Is the PEP clear that you have to hold the GIL for these calls?
(Can't hurt to be explicit, given the fact that one intention is to
*use* the buffer while the GIL is released...

--Guido van Rossum (home page: http://www.python.org/~guido/)