[Pyrex] Pyrex and the GIL

[Greg Ewing]

Andrew Bennetts wrote:

> Anyone wanting to write callbacks to pass to C functions is surely going to
> need this, if by "don't care" you mean "needs GIL, and will acquire it if
> necessary."

No, it simply means that, to calling code, it doesn't matter
whether the GIL is held or not when the call is made.

If the function is written in Pyrex and uses Python opeations,
then clearly it does need the GIL, so the compiler must
insert code to acquire it. Probably this will be done using
PyThreadState_Ensure, so the exact semantics will be "don't
care". Interpreting it from the outside as "requires GIL
released" is stricter than necessary, but not harmful.

> Hmm, I think ensures_gil sounds like part of the signature myself -- it's
> declaring something about the state of the world that the function expects

But it could also be taken to imply that it does actually
acquire the GIL if it's not already held, which is a property
of the implementation.

I suppose it's a minor point, but I'm fussy about that sort
of thing. :-)

Hmmm. Maybe the three cases could be

    gil           # requires GIL held, default
    nogil         # requires GIL released
    gil or nogil  # doesn't care

> How about:
> 
>     @ensures_gil
>     cdef int frobnicate(int result):

Urg! I was hoping to be able to keep the decorator syntax
out of Pyrex. I suppose inevitably someone is going to want
it... :-(

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg.ewing at canterbury.ac.nz	   +--------------------------------------+