--- 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4