On 16 March 2011 13:55, mark florisson <markflorisso...@gmail.com> wrote: > On 16 March 2011 13:37, Dag Sverre Seljebotn <d.s.seljeb...@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.seljeb...@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. >
I have to mention, though, that the converse is not true. The gil may be acquired recursively, i.e., 'with gil:' blocks may be nested. _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
