[Cython] 'with gil:' statement
Dag Sverre Seljebotn
d.s.seljebotn at astro.uio.no
Wed Mar 16 11:58:28 CET 2011
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
I think we should make nested nogil-s noops, i.e.
with nogil: # => if True:
This is because one may want to change "with nogil" to "with gil" for
debugging purposes (allow printing debug information).
Another feedback is that I wonder whether we should put the "gil" and
"nogil" psuedo-context managers both in cython namespace, and sort of
deprecate the "global" nogil, rather than introduce yet another name
that can't be used safely for all kinds of variables.
> The 'with gil:' statement can now be used in the same way as 'with
> nogil:'. Exceptions raised from GIL blocks will be propagated if
> possible (i.e., if the return type is 'object'). Otherwise it will
> jump to the end of the function and use the usual
> __Pyx_WriteUnraisable, there's not really anything new there.
> For functions declared 'nogil' that contain 'with gil:' statements, it
> will safely lock around around the initialization of any Python
> objects and set up the refnanny context (with appropriate preprocessor
> guards). At the end of the function it will safely lock around the
> teardown of the refnanny context. With 'safely' I mean that it will
> create a thread state if it was not already created and may be called
> even while the GIL is already held (using PyGILState_Ensure()). This
> means variables are declared and initialized in the same way as in
> normal GIL-holding functions (except that there is additional
> locking), and of course the GIL-checking code ensures that errors are
> issued if those variables are attempted to be used outside any GIL
> Could someone review the patch (which is attached)? Maybe check if I
> haven't missed any side cases and such?
> cython-devel mailing list
> cython-devel at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cython-devel