Stefan Behnel wrote: > I think this is the one case where exception propagation will easily work > in a nogil block. If we get the exception propagation semantics right here, > we can leave this in. But it's not entirely clear (at least to me) if this > currently behaves 'correctly'. > > It *might* be possible to enable the same for "except *" somehow, but until > then, Cython should raise an error at compile time rather than letting the > code crash at runtime.
I think we can pull of except * without the GIL: When releasing the GIL, we get a PyThreadState* pointing to our current thread state, in _save. When nested functions reacquire the GIL in order to construct and raise an exception, they should get the same PyThreadState* object. So back in our original function, we can simply directly inspect _save->exc_type rather than use PyErr_Occurred. All in all I propose this: - It is possible to raise exceptions from a nogil context, by fetching the GIL temporarily to raise the exception, release the GIL, and return the normal exceptional way. - In order to propagate the exception, nogil code can look at _save->exc_type, which is very fast. - If returning from a nogil function with an exception set, the function will acquire the GIL, push exception stack information, and release the GIL. This will mean that a) Normally nogil code does not acquire the GIL. b) If an exception is raised, the GIL is still acquired/reacquired, once per stack level. -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
