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