On 03/17/2011 08:38 AM, Dag Sverre Seljebotn wrote:
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.)
Heh. I obviously meant that "removing it would slow down serial code".
Dag
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
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
