Dan Roberts, 10.05.2010 23:12:
> I've been digging pretty deep to try and
> see what's so special about __Pyx_GetException() and the only thing I see is
> that it copies curexc_* fields into exc_* fields. I've dug around in the
> CPython source and I'm having a hard time figuring out the importance of
> exc_*
curexc_* holds the exception that is currently being raised, so it signals
an uncaught exception. exc_* is what you see in sys.exc_info(). Basically,
the exception is being moved there when it's getting caught somewhere. A
newly raised exception inside of an except block would then land in
curexc_*, so that both the old and the new one stay available. Only exc_*
is readable from Python space, curexc_* is hidden behind the raise and
except statements.
In Python3, there are some additional features that make old exceptions
available as part of a newly raised exception ('cause' and friends), and
that remove an exception from exc_* when the except block that caught it is
being left. This kind of differences makes it tricky to work on that code,
but the Py3 exception handling code in Cython was certainly simplified a
lot by moving back to standard C-API functions.
> If we could establish that, we could build a new __Pyx_GetException()
> that only relies on PyErr_Fetch(). (The only other thing is
> __Pyx_GetException() deals with refcounts too, but that could be added
> easily)
Right, PyErr_Fetch() is only manually inlined here since the code needs to
access the PyThreadState fields anyway.
I don't think __Pyx_GetException() is sufficiently performance critical in
its current form to merit this kind of inlining, though, and PyErr_Fetch()
hasn't changed between Py2.3 and Py3k HEAD, so I'm fine with a cleanup.
There's also a code duplication in the exception fetch/restore code, which
is basically done for C inlining since this can happen a lot, e.g. during
'finally' statements. I think that code is fine and should stay as is, with
the obvious fallback to the normal C-API functions on non-CPython runtimes.
I haven't looked at the exception raising code yet, but I'm pretty sure
there are issues, too.
> I'm glad you're open to having multiple implementations, that way everyone
> is happy :-) I suppose since I've brought this up, and I'm most immediately
> affected, it falls to me to implement. That's fine as long as it doesn't
> take my whole summer :-p. And hopefully someone will be willing to guide me
> and answer my possibly dumb questions. I see that cython has a healthy
> heaping of tests too, which should help in determining compliance. I think
> I'm up to the challenge... I think...
Thanks for volunteering, and for bringing these issues up in the first place.
Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
