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 pitrou
Recipients Mekk, eric.snow, gvanrossum, ncoghlan, pitrou, steve.dower, vstinner, xcombelle
Date 2017-12-04.12:14:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> I guess that the intent of dynamically created GIL is to reduce the "overhead" of the GIL when 100% of the code is run in single thread.

I'm not sure it is ok to guess here.  The original code was written in 1992, when system threading APIs were buggy and not always available.  Also the original GIL logic released the lock every N opcodes, which is a fragile heuristic.  The current GIL shouldn't have any visible performance cost in single-threaded mode, and in even in multi-threaded mode it's been a long time since anyone complained about a real-world performance degradation due to the GIL's overhead.

Perhaps Guido remembers the original rationale?

> This bug was reported once in 2014, then Marcin Kasperski asked for an update last month: 3 years later. It's not a common bug impacting many users.

From a maintenance POV, initializing the GIL eagerly also makes maintenance easier for us, instead of making all those dynamic checks.
Date User Action Args
2017-12-04 12:14:31pitrousetrecipients: + pitrou, gvanrossum, ncoghlan, vstinner, Mekk, eric.snow, steve.dower, xcombelle
2017-12-04 12:14:31pitrousetmessageid: <>
2017-12-04 12:14:31pitroulinkissue20891 messages
2017-12-04 12:14:31pitroucreate