[Cython] 'with gil:' statement

[Dag Sverre Seljebotn]

On 03/16/2011 01:55 PM, mark florisson wrote:
> On 16 March 2011 13:37, Dag Sverre Seljebotn<d.s.seljebotn at astro.uio.no>  wrote:
>> On 03/16/2011 12:54 PM, mark florisson wrote:
>>> On 16 March 2011 11:58, Dag Sverre Seljebotn<d.s.seljebotn at astro.uio.no>
>>>   wrote:
>>>> On 03/16/2011 11:28 AM, mark florisson wrote:
>>>>
>>>> I implemented the 'with gil:' statement, and have added error checking
>>>> for nested 'with gil' or 'with nogil' statements. For instance, with
>>>> the patch applied Cython wil issue an error when you have e.g.
>>>>
>>>> with nogil:
>>>>      with nogil:
>>>>          ...
>>>>
>>>> (or the same thing for 'with gil:'). This because nested 'nogil' or
>>>> 'gil' blocks, without intermediate GIL-acquiring/releasing, will abort
>>>> the Python interpreter. However, if people are acquiring the GIL
>>>> manually in nogil blocks and then want to release the GIL with a
>>>> 'nogil' block, it will incorrectly issue an error. I do think this
>>>> kind of code is uncommon, but perhaps we want to issue a warning
>>>> instead?
>>>>
>>>> I think we should make nested nogil-s noops, i.e.
>>>>
>>>> with nogil:
>>>>      with nogil: # =>    if True:
>>>>
>>>> This is because one may want to change "with nogil" to "with gil" for
>>>> debugging purposes (allow printing debug information).
>>> Interesting, that does sound convenient, but I'm not if mere
>>> convenience should move us to simply ignore what is technically most
>>> likely incorrect code (unless there is intermediate manual locking).
>> I'm not sure if I understand what you mean here. How does simply ignoring
>> redundant "with [no]gil" statements cause incorrect code? Or do you mean
>> this is a
>>
>> I'm just trying to minimize the "language getting in your way" factor. It is
>> pretty useless to write
>>
>> if x:
>>     if x:
>>         ...
>>
>> as well, but Python does allow it.
>>
>> Warnings on nested "with nogil" is more the role of a "cylint" in my
>> opinion.
>>
> Perhaps you're right. However, I just think it is important for users
> to realize that in general, they cannot unblock threads recursively.
> Currently the error checking code catches multiple nested 'with
> (no)gil', but it doesn't catch this:
>
> cdef void func() nogil:
>      with nogil:
>          pass
>
> with nogil:
>      func()
>
> But the problem is that it does abort the interpreter. So I thought
> that perhaps emphasizing that that code is incorrect for at least the
> easy-to-catch cases, we might make users somewhat more aware. Because
> if the above code aborts Python, but a nested 'with nogil:' is valid
> code, there might be a source for confusion.

Ah, right. I guess I agree with disallowing nested "with nogil" 
statements for the time being then.

Dag Sverre