[Cython] 'with gil:' statement

[Dag Sverre Seljebotn]

On 03/17/2011 12:24 AM, Greg Ewing wrote:
> Stefan Behnel wrote:
>
>> I'm not sure if this is a good idea. "nogil" blocks don't have a way 
>> to handle exceptions, so simply jumping out of them because an inner 
>> 'with gil' block raised an exception can have unexpected side effects.
>
> Seems to me that the __Pyx_WriteUnraisable should be done at
> the end of the 'with gil' block, and execution should then
> continue from there.
>
> In other words, the effect on exception handling should be
> the same as if the 'with gil' block had been factored out into
> a separate function having no exception return value.
>

-1.

I consider the fact that exceptions don't propagate from some functions 
a "currently unfixable bug". We should plan for it being fixed some day. 
Having a "with" statement alter execution flow in this way is totally 
unintuitive to me.

If you want this, it's better to introduce a new keyword like 
"trywithgil: ... except:" (not that I'm in favour of that).

We could perhaps fix exception propagation from nogil functions by using 
some conventions + setjmp/longjmp. Mono does this when calling into 
native code, and I recently did it manually in Cython to propagate 
exceptions through the Fortran wrappers in SciPy. Also, the GIL may not 
be around forever even in CPython? (All arguments I've seen for keeping 
it has been along the lines of "it slows down serial code", not that it 
is considered a good thing.)

Designing a language around the GIL feels like a dead-end to me. I'm OK 
with being practical in the face of the limitations of today; but let's 
keep "with gil" and "with nogil" something that can become noops in the 
future without too much pain. Yes, I know that if the GIL goes it will 
break Stefan's lxml code, and I'm sure other code -- I'm just saying 
that we shouldn't make the language design even more GIL-centric than it 
already is.

Anyway, I'm off to write some computational Fortran+OpenMP code because 
dealing with threading and Python is just more than I can deal with...

Dag Sverre