Author pablogsal
Recipients eric.snow, pablogsal, pitrou, vstinner
Date 2019-03-25.22:14:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1553552075.96.0.382616254369.issue36427@roundup.psfhosted.org>
In-reply-to
Content
Currently PyEval_RestoreThread and its callers (mainly PyGILState_Ensure) can terminate the thread if the interpreter is finalizing:

PyEval_RestoreThread(PyThreadState *tstate)
{
    if (tstate == NULL)
        Py_FatalError("PyEval_RestoreThread: NULL tstate");
    assert(gil_created());

    int err = errno;
    take_gil(tstate);
    /* _Py_Finalizing is protected by the GIL */
    if (_Py_IsFinalizing() && !_Py_CURRENTLY_FINALIZING(tstate)) {
        drop_gil(tstate);
        PyThread_exit_thread();
        Py_UNREACHABLE();
    }
    errno = err;

    PyThreadState_Swap(tstate);
}

This behaviour that protects against problems due to daemon threads registered with the interpreter can be *very* surprising for C-extensions that are using these functions to implement callbacks that can call into Python. These callbacks threads are not owned by the interpreter and are usually joined by someone else, ending in deadlocks in many situations.

I propose to add a warning to the documentation to inform users about this situation.
History
Date User Action Args
2019-03-25 22:14:35pablogsalsetrecipients: + pablogsal, pitrou, vstinner, eric.snow
2019-03-25 22:14:35pablogsalsetmessageid: <1553552075.96.0.382616254369.issue36427@roundup.psfhosted.org>
2019-03-25 22:14:35pablogsallinkissue36427 messages
2019-03-25 22:14:35pablogsalcreate