[Cython] 'with gil:' statement

Stefan Behnel stefan_ml at behnel.de
Fri Mar 18 13:36:01 CET 2011

Dag Sverre Seljebotn, 18.03.2011 12:07:
> On 03/18/2011 11:10 AM, Stefan Behnel wrote:
>> 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.

That's a bit exaggerated, IMHO. I would expect that there'd be many cases 
where the right thing to do in case of an exception is to return from a 
function, with a bit of explicit cleanup. So many exceptions won't leave 
the "with gil" block anyways. And few users will actually use nested "with 
gil" and "nogil" blocks.

But still, there's the question how code that re-acquires the GIL should 
behave (still thinking of a callback case here). Should it check for a 
raised exception and jump into the exception handling path? Or should it 
ignore it and continue until something tests for the exception explicitly? 
And what if intermediately running nogil code changed some state somewhere 
that breaks the exception handling path? Or what if the code block that 
temporarily re-acquires the GIL (e.g. a logging handler) is completely 
unrelated to the one that actually raised the exception or the one that 
called into the whole machinery (and that would be the right one to handle 
it)? These things are not trivial, neither for Cython's language semantics 
nor for users.

We shouldn't forget that basically all Python operations can at least raise 
a MemoryError or a KeyboardInterrupt etc. Most users won't think of these 
cases. I think it would help users in writing safer code if the need to 
handle exceptions in nogil blocks was always made explicit by the compiler. 
That's different from "not supporting something".

> Relying on boolean flags to signal errors states is a real pain
> when one is used to using exceptions.

Well, if those exception do not take safe and obvious paths, it may still 
be better to use explicit boolean flags instead.

Specifically, I'm fine with letting exceptions flow through nogil code iff 
there is a way to react on exceptional exit paths inside of nogil blocks. 
I'm against enabling "except" clauses in nogil blocks, but I think a 
try-finally would catch the most important use cases iff we can figure out 
clean semantics for this, including the cases I mentioned previously. 
That's the condition I see.


More information about the cython-devel mailing list