This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients Mekk, eric.snow, ncoghlan, pitrou, steve.dower, vstinner, xcombelle
Date 2017-12-04.11:59:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> Why not *always* call PyEval_InitThreads() at interpreter initialization?  Are there any downsides?

The code is quite old:

commit 1984f1e1c6306d4e8073c28d2395638f80ea509b
Author: Guido van Rossum <>
Date:   Tue Aug 4 12:41:02 1992 +0000

    * Makefile adapted to changes below.
    * split pythonmain.c in two: most stuff goes to pythonrun.c, in the library.
    * new optional built-in threadmodule.c, build upon Sjoerd's thread.{c,h}.
    * new module from Sjoerd: mmmodule.c (dynamically loaded).
    * new module from Sjoerd: sv (, svmodule.c.proto).
    * new files thread.{c,h} (from Sjoerd).
    * new xxmodule.c (example only).
    * myselect.h: bzero -> memset
    * select.c: bzero -> memset; removed global variable


+#ifdef USE_THREAD
+       if (interpreter_lock)
+               fatal("2nd call to init_save_thread");
+       interpreter_lock = allocate_lock();
+       acquire_lock(interpreter_lock, 1);

Current version of the code:

    if (gil_created())
    _PyRuntime.ceval.pending.main_thread = PyThread_get_thread_ident();
    if (!_PyRuntime.ceval.pending.lock)
        _PyRuntime.ceval.pending.lock = PyThread_allocate_lock();
Date User Action Args
2017-12-04 11:59:07vstinnersetrecipients: + vstinner, ncoghlan, pitrou, Mekk, eric.snow, steve.dower, xcombelle
2017-12-04 11:59:07vstinnersetmessageid: <>
2017-12-04 11:59:07vstinnerlinkissue20891 messages
2017-12-04 11:59:07vstinnercreate