[Cython] 'with gil:' statement

[Dag Sverre Seljebotn]

On 03/18/2011 11:10 AM, Stefan Behnel wrote:
> mark florisson, 18.03.2011 10:52:
>> On 18 March 2011 07:07, Stefan Behnel wrote:
>>> Greg Ewing, 18.03.2011 01:18:
>>>>
>>>> mark florisson wrote:
>>>>>
>>>>> I think we could support it without having to acquire
>>>>> the GIL in the finally clause.
>>>>
>>>> That was the intention -- the code in the finally clause would
>>>> be subject to the same nogil restrictions as the rest of
>>>> the nogil block.
>>>>
>>>> My point is that as long as you're allowing exceptions to be
>>>> tunnelled through nogil blocks, they should respect any finally
>>>> clauses that they pass through on the way.
>>>
>>> +1
>>
>> Ok, I will give it a go and try to allow it when they surround with
>> gil blocks. I would however like to reiterate that it is a
>> special-case, inconsistent with previous behaviour, and basically
>> extends the language and won't work for functions that are called and
>> declared 'with gil'. But it is convenient, so I can't help but like it
>> at the same time :]
>
> I'm not sure I understand why you think it's so bad, and why it would 
> be inconsistent with previous behaviour.
>
> The only real problem I see is that you could do things like this:
>
>     with nogil:
>         try:
>             with gil: raise ...
>         finally:
>             with gil: raise ...
>
> i.e. you could loose the original exception. Even worse:
>
>     with nogil:
>         try:
>             with gil: raise ...
>         finally:
>             with gil:
>                 try: raise
>                 except: pass
>
> Here, it must be made sure that the original exception still gets 
> raised properly at the end. That's a problem in Py2, where exceptions 
> are badly scoped, i.e. Python code that runs in the interpreter could 
> fail to reset the original exception after catching another one. But I 
> guess these things are up to the "with gil" block/function, rather 
> than the above "finally" clause.
>
> Actually, I think I still find it more convenient to not provide *any* 
> special exception paths through nogil code, i.e. to not let exceptions 
> in "with gil" blocks exit from outer "nogil" blocks. That would avoid 
> all of the semantic difficulties above.

Well, of course not supporting something is easier. But is it user 
friendly? Relying on boolean flags to signal errors states is a real 
pain when one is used to using exceptions.

Dag Sverre