On Apr 15, 2009, at 12:14 AM, Dag Sverre Seljebotn wrote:

> 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.

In other words, you're changing the definition of nogil to be "gets  
the GIL if it needs" rather than "doesn't use (or need) the GIL."  
Granted, exceptions are exceptional, but I'm still a bit wary.  
Specifically, can implicitly acquiring the GIL for this cause block  
and/or lead to deadlock/race conditions?

- Robert


_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to