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

[Scott Gilbert]

--- Guido van Rossum <guido@python.org> wrote:
> > > >         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.)

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.




Cheers,
    -Scott


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com