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.
Stefan
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
