blogs/event-loop-and-multithread-in-python/

[utterances-bot]

Python中的Event Loop和多线程 | BoHolder的网站：博客，小玩意及其他

因工作接触Python Web，又稍微往底层和延伸搜了搜

https://boholder.github.io/blogs/event-loop-and-multithread-in-python/

[boholder]

非常推荐bbc博客上的系列asyncio教程，很详细清楚，作者必然是个熟知多个计算机领域的人，那个try-else用法不是新手能写出来的。 https://bbc.github.io/cloudfit-public-docs/asyncio/asyncio-part-5.html#watching-file-descriptors

[boholder]

这篇文章 https://pythonspeed.com/articles/python-gil/ 通过实证提供了很多知识，我在这里摘抄一下结论：

1. A thread must hold the GIL to call CPython C APIs.
2. Python code running in the interpreter, like x = f(1, 2), uses those APIs. Every == comparison, every integer addition, every list.append: it’s all calls into Python C APIs. Thus threads running Python code must hold on to the lock when running.
3. Other threads can’t acquire the GIL, and therefore can’t run, until the currently running thread releases it, which happens every 5ms automatically.
4. Long-running (“blocking”) extension code prevents the automatic switching.
5. Python extensions written in C (or other low-level languages) can however explicitly release the GIL, allowing one or more threads to run in parallel to the GIL-holding thread.

文章下面还列举了python内调用各种语言的扩展是否能释放GIL。 我搜到如果是通过PyO3的rust扩展的话，默认是在rust代码执行时也持有GIL，除非显式释放： https://pyo3.rs/v0.9.2/parallelism

所以这篇bbc博客里写的 “However, if a Python method calls out to native code for some purpose then the GIL will normally be released.” 在某种程度上是不对的。 https://bbc.github.io/cloudfit-public-docs/asyncio/asyncio-part-5.html#what-about-the-global-interpreter-lock