我花了整整四年才解决这个bug！程序员果真不是一般人能做的！

概述进群：548377875 加入万人交流基地！我的第一个评论是：以我之愚见，这是PyEval_InitThreads()中的一个Bug。

进群：548377875  加入万人交流基地！

我的第一个评论是：

以我之愚见，这是PyEval_InitThreads()中的一个BUG。

修复PyGILState_Ensure()

2年的时间里，我完全不记得这个BUG了。 2016年3月，我修改了Steve的测试程序，使其与linux兼容（该测试是为windows编写的）。 我成功地重现了我电脑上的错误，并且为PyGILState_Ensure()写了一个修复程序。

一年后，2017年11月，卡辛斯基问道：

此修复发布了吗？ 我在更新日志中找不到...

哎呀，我又完全忘记了这个问题！ 这一次，我不仅安装了我的PyGILState_Ensure()修复，还编写了单元测试test_embed.test_bpo20891()：

好的，这个BUG现在已经在Python 2.7,3.6 和master（将来的3.7）中得到解决。 在3.6和master版本中，此修复带有单元测试。

我的主分支的修复，提交b4d1e1f7：

 

 

于是我关闭了问题bpo-20891 ...

macOS上测试发生随机崩溃

一切都很好......但一周后，我注意到我新增加的单元测试在macOS buildbots上发生了随机崩溃。 我成功地手动重现了这个BUG，第三次运行时崩溃的例子：

 

 

macOS上的test_embed.test_bpo20891()在PyGILState_Ensure() 中显示有竞态条件(race condition)：GIL锁本身的创建...没有被加锁保护！ 添加一个新的锁来检查Python是否有GIL锁，好像没有意义...

我提出了PyThread_start_new_thread()的一个不完整的修复：

我发现有一个修复是管用的：在PyThread_start_new_thread()中调用PyEval_InitThreads()。 那么，一旦生成第二个线程就会创建GIL锁。 当两个线程正在运行时，GIL不能再创建。 至少，用python代码不可以建。 如果一个线程不是由Python产生的话，此修复不能解决这个问题，但是这个线程调用了PyGILState_Ensure()。

为什么不始终创建GIL？

Antoine Pitrou问了一个简单的问题：

为什么不在解释器初始化时总是调用PyEval_InitThreads()？ 有什么缺点吗？

当然在学习Python的道路上肯定会困难，没有好的学习资料，怎么去学习呢？

所以小编准备了一份零基础入门Python的学习资料。关注，转发，私信“007”即可领取！

感谢git blame和git log，我发现了“按需”创建GIL的代码，来自于26年前做出的改变！

 

 

我的猜测是，动态创建GIL的目的是为了减少GIL的“开销”。这些GIL用于那些只使用单个Python线程的应用程序（永远不会产生新的Python线程）。

幸运的是，GuIDo van Rossum在我附近，能够对基本原理加以阐述：

是的，最初的理由是线程是深奥的，不为大多数代码所使用，并且当时我们一定觉得：总是使用GIL会导致（微小的）速度放缓，并增加由于GIL代码中的错误而导致崩溃的风险。 我很高兴得知我们不再需要担心这一点，并且可以始终对其进行初始化。

提出Py_Initialize()的第二个修复

我提出了Py_Initialize()的第二个修复，以便在Python启动时始终创建GIL，并且不再“按需”，以防止出现竞态条件的风险：

 

 

Nick Coghlan问我是否可以通过性能基准测试我的补丁。 我在我的PR 4700上运行pyperformance。差异至少5％：

 

 

哦，5个基准比较慢。 Python中性能退步是不受欢迎的：我们正在努力让Python变得更快！

在圣诞节前忽略错误测试

我没有想到5个基准测试会变慢。 我需要进一步的调查，但时间不够。也许是我太害羞，或者羞于承担导致性能退步的责任。

在圣诞节假期之前，我没有做任何决定，而test_embed.test_bpo20891()在macOS buildbots上仍然是随机失败。 在离开两个星期之前，我对于触及Python的关键部分，即GIL，并没有太多把握。 所以我决定，等到我回来之前，先跳过test_bpo20891()。

没有圣诞礼物给你了：Python 3.7。

运行新的基准测试，和应用于master的第二个修复

在2018年1月底，我再次运行了那5个由于我的PR(Pull request)而变慢的基准测试。 我使用了cpu隔离，在我的笔记本电脑上手动运行这些基准测试：

 

 

好吧，它证实了，依照Python性能基准套件，我的第二个修复对性能没有显著的影响。

我决定将我的修复程序推送到master分支，提交2914bb32：

 

 

然后我在master分支上重新启用了test_embed.test_bpo20891()。

没有适用于Python 2.7和3.6的第二个修复，抱歉！

Antoine Pitrou认为，不应该合并Python 3.6的backport （注：backport是将一个软件的补丁应用到比此补丁所对应的版本更老的版本的行为）：

我不这么认为。 人们可能已经调用PyEval_InitThreads()。

GuIDo van Rossum也不想把这一修改做backport。 所以我只从3.6的分支中删除了test_embed.test_bpo20891()。

由于相同的原因，我没有将我的第二个修复应用于Python 2.7。 而且，Python 2.7没有单元测试，因为它很难backport。

至少，Python 2.7和3.6获得了我的第一个PyGILState_Ensure()修复。

结论

在少数案例中，Python仍然存在一些竞态条件。 当一个C线程开始使用Python API时，在创建GIL时就可以发现这样的BUG。 我推出了第一个修复程序，但在macOS上发现了一个新的不同的竞态条件。

我不得不深入研究Python GIL的历史（1992年）。 幸运的是，GuIDo van Rossum也能够阐述其基本原理。

在基准测试出现故障后，我们同意修改Python 3.7，以便始终创建GIL，而不是按需创建GIL。 该变化对性能没有显著的影响。

我们还决定让Python 2.7和3.6保持不变，以防止任何回退风险：可以继续按需创建GIL。

我花了4年的时间修复了Python GIL中的一个令人讨厌的BUG。 在接触Python中如此关键的部分时，我从未自信满满。 现在，我很高兴这个BUG被我们甩在了身后：现在，它已经在未来的Python 3.7中完全修复了！

完整的故事见bpo-20891。 感谢帮助我解决这个BUG的所有开发人员！

总结

以上是内存溢出为你收集整理的我花了整整四年才解决这个bug！程序员果真不是一般人能做的！全部内容，希望文章能够帮你解决我花了整整四年才解决这个bug！程序员果真不是一般人能做的！所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。