[Pyrex] [Cython-dev] Callbacks from threads and PyGILState_Ensure/PyGILState_Release

[Greg Ewing]

Stefan Behnel wrote:
> it's
> actually two things you were trying to catch with the "nogil" annotation:
> 
> - "this can safely execute without the GIL", which Pyrex can verify and even
> figure out based on function bodies, but which it needs to be told for
> external functions

That's correct.
> 
> and the second being
> 
> - "this *will* be executed without the GIL",

I wouldn't describe it quite that way. When you use 'nogil' on
the *implementation* of a function, you're asserting "This
function *must* be callable without the GIL". It's then up
to Pyrex to do whatever is necessary to make that true.

A fully smart implementation would analyse the body to
determine whether the GIL needed to be acquired, based on
the nogil status of the things it calls.

A completely naive implementation would always acquire
the GIL, just in case, although that might be inconvenient,
as then you wouldn't be able to write pure-C non-GIL-using
functions in Pyrex.

A middle ground would be to provide another annotation
somehow to tell Pyrex to acquire the GIL, such as

   cdef void myfunc() acquires GIL:
     ...

where 'acquires GIL' would also imply 'nogil'.

Another way would be to write

   cdef void myfunc() nogil:
     with GIL:
       ...

and have Pyrex recognise 'with GIL' at the top level of
the body as a special case and generate GIL-acquiring code
around everything. I'm leaning towards this, because it
would avoid introducing a notation that would become
obsolete later with a smarter implementation.

--
Greg



  which Pyrex cannot know and has
> to be told to acquire the GIL if necessary.
> 
> I'm not sure the two fit into one keyword.
> 
> Maybe a "nopython" annotation for external functions and a smarter Pyrex would
> fit the first, while a "nogil" function annotation would match the second?
> 
> Stefan
>