[Python-Dev] PEP 298, final (?) version
Sat, 3 Aug 2002 13:44:17 -0700 (PDT)
--- Guido van Rossum <firstname.lastname@example.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.
Do You Yahoo!?
Yahoo! Health - Feel better, live better