Allow Interpreter.prepare_main() Even If the Interpreter Is Running?
還沒有人認領這個 Issue。
- 主要語言
- Python
- 星號
- 77.2k
- 分支
- 36k
- PR 合併指標
- PR 指標待擷取
描述
Feature or enhancement
Proposal:
Currently Interpreter.prepare_main() (from concurrent.interpreters) fails if the interpreter is running. (See Interpreter.is_running(). It may make sense to relax this restriction.
For example, it might make sense for a subinterpreter to call prepare_main() on the main interpreter to share a cross-interpreter Queue. Currently that fails because the main interpreter is always considered to be "running".
The answer for now is "make sure the main interpreter creates any queues it needs to share" and that might be good enough.
It's something I hadn't considered before and I'm not exactly sure yet that allowing it would be the right thing. The problem is that it isn't intuitively obvious to users (or me) how externally modifying an interpreter's __main__ module may affect code running there in a different thread.
Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
No response
貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
研究方向
先檢視 concurrent.interpreters.Interpreter.prepare_main() 和 Interpreter.is_running(),著重了解為何會拒絕對正在執行的直譯器進行準備。判斷允許從外部變更 main 在不同執行緒和子直譯器之間是否安全,然後在變更此限制之前定義所需的行為和測試。
由索引模型根據 Issue 內容生成。
評估
- 技術堆疊
- python
- 領域
- backend
- Issue 類型
- 功能
- 難度
- 5/5
- 預估耗時
- 一週以上
- 活躍度
- 停滯
- 描述清晰度
- 需要釐清
- 新手友好度
- 25/100