PyGILState_Ensure should not deadlock if GIL already held

Issue #1778 resolved
Nick Williams created an issue

PyGILState_Ensure is documented as "(ensuring) that the current thread is ready to call the Python C API regardless of the current state of Python, or of the global interpreter lock".

However, in PyPy, code which calls PyGILState_Ensure while already holding the GIL will deadlock. This does not happen in CPython and does not seem consistent with the Python documentation.

Comments (7)

  1. Nick Williams reporter

    If you could point me to an existing test which requires the building of an extension module I'd be happy to so that.

  2. mattip

    pypy/modules/cpyext/test/test_thread.py has examples of tests that PyPy can run untranslated, any of the ones that have c code as part of import_extension should serve as an example. Then the test would be run by using pytest, assuming you add a test called test_gilstate_ensure:

    python pytest.py pypy/module/cpyext/test/test_thread.py -k test_gilstate_ensure

    Alternatively, lib-python/2.7/test has cpython stdlib tests, you can add corresponding c code in lib_pypy/_testcapimodule.c, Then we could add a patch to upstream cpython's tests so that other python implementations could also make sure they are compatible with cpython

  3. sbehnel

    There is this comment in pystate.py, BTW:

    # XXX XXX XXX THIS IS A VERY MINIMAL IMPLEMENTATION THAT WILL HAPPILY
    # DEADLOCK IF CALLED TWICE ON THE SAME THREAD, OR CRASH IF CALLED IN A
    # NEW THREAD.  We should very carefully follow what CPython does instead.
    
  4. Log in to comment