Robert Bradshaw wrote:
>> This will mean that
>> a) Normally nogil code does not acquire the GIL.
>> b) If an exception is raised, the GIL is still acquired/reacquired,
>> once
>> per stack level.
>
> In other words, you're changing the definition of nogil to be "gets
> the GIL if it needs" rather than "doesn't use (or need) the GIL."
> Granted, exceptions are exceptional, but I'm still a bit wary.
> Specifically, can implicitly acquiring the GIL for this cause block
> and/or lead to deadlock/race conditions?
Thanks, that was very helpful to my thoughts. I'll be clearer.
This is actually two orthogonal issues:
I) Exception propagation in nogil.
The following currently works and is fully supported:
cdef int raise_some_error() except -1 with gil:
raise ValueError("test")
def f():
cdef int a
try:
with nogil:
a = 0
if 1 + 1 == 2: # very exceptional case
raise_some_error()
a = 1
except ValueError:
a = 3
print a # prints 3
However "except *" is not supported, which is a limitation to this.
II) Whether division and buffer access is allowed to imply a hidden
"with gil" section in their exceptional cases.
To answer your question: The only thing I can think of is if you start
spawning new threads using C functions; then reacquiring the GIL will
fail using those threads, and calling functions declared "with gil" is
perhaps more explicit and can more easily be avoided. (But that's a
rather expert case and there's always compiler directives.)
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
