[Pyrex] Pyrex and the GIL

[Andrew Bennetts]

On Mon, Sep 12, 2005 at 09:45:58PM +1200, Greg Ewing wrote:
> Andrew Bennetts wrote:
> 
> >You're talking about case 1, and I'm happy enough with "nogil" for that.  I
> >think "ensures_gil" would be a saner name for case 2, though -- after all,
> >I presume it would be implemented using PyGILState_Ensure, which exists for
> >that purpose.
> 
> Perhaps, although we're back to the question of whether
> it's worth explicitly providing for a "don't care" case.
> It's not strictly necessary, since if it doesn't care,
> it does no harm to release the GIL before calling it,
> should it ever be called directly from Pyrex code.

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."  If by "don't care" you mean "doesn't do any operations that
need the GIL, so the GIL is irrelevant", then I can't say I'm much worried.

I do have a small confession though: I'm not using Pyrex much at the moment,
so my opinions are largely hypothetical rather than grounded in concrete
use-cases.

> An important thing to keep in mind is that these are
> properties of the function signature, and whatever
> names they're given, they need to make sense from both
> inside and outside the function, and whether the function
> is implemented in Pyrex or not. So, for example,
> "ensures_gil" is not appropriate, because it says
> something about the function's implementation, not
> its signature.

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
(in this case that it's tolerant of gil being held or not), which in turns
affects how it is called.  I suppose this is a matter of taste.

    cdef int frobnicate(int result) ensures_gil:
        ...

That reads ok to me.  I think I can see what you're saying though; in
principle this could be:

    cdef int frobnicate(int result):
       ...
       needs_gil:
          ...
       ...

But I agree with your other post saying that function boundaries are a good
place for these declarations, and in some sense the fact that ensures_gil is
deliberately agnostic about the GIL being held or not is a special case.
Hmm...

How about:

    @ensures_gil
    cdef int frobnicate(int result):
        ...

<0.5 wink>

-Andrew.