[Pyrex] Pyrex and the GIL

[Bob Ippolito]

On Sep 11, 2005, at 11:18 PM, Andrew Bennetts wrote:

> On Mon, Sep 12, 2005 at 05:24:18PM +1200, Greg Ewing wrote:
>
>> Bob Ippolito wrote:
>>
>>
>>>> That's not right either, because when calling
>>>> out to such a function you need to ensure that
>>>> the GIL is *not* held.
>>>>
>>
>>
>>> Not really, the PyGILState_Ensure() API doesn't care.
>>>
>>
>> The uses I have in mind for declaring an external
>> function nogil are where the function does something
>> that you want done with the GIL released, such as
>> reading from a file. The function itself probably
>> knows nothing about Python.
>>
>
> That's a different case -- aren't we talking about two seperate  
> cases here:
>
>   1) an external function that we wish to declare doesn't need the  
> GIL to be
>      held when a pyrex function calls it.
>   2) a pyrex function that may be called when GIL isn't held, but  
> needs it,
>      e.g. to be passed as a callback to a C library.
>
> 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.

I don't really see 1 being very important.. the default case does  
nothing to acquire or release the GIL anywhere, which is probably  
something you want to control yourself explicitly.  Case 2 I've seen  
come up pretty often in writing wrappers for 3rd party code that uses  
threads or event loops.

Perhaps there should be a "try:finally:" style construct for doing  
some chunk of code without the GIL?  That seems to make a lot more  
sense than trying to do it at function boundaries.  PyGILState_Ensure  
*does* make sense for doing at function boundaries, though.

-bob