テクノロジー · 実用ガイド
Python の「bootstrapping phase」は、spawn が再 import する経路を先に証明
child interpreter が entry module を再 import 中に、import path がもう一度 process を開始したことを示します。start method と launcher を記録し、完全な生成経路を entry boundary の内側へ移します。
child interpreter が entry module を再 import 中に、import path がもう一度 process を開始したことを示します。start method と launcher を記録し、完全な生成経路を entry boundary の内側へ移します。
元の launcher から再実行し、parent が一つだけ起動し、意図した workers が一度ずつ実行され、process method の強制変更なしで正常終了して初めて修復完了です。
1. 失敗した launch path を固定
最初の RuntimeError の完全な traceback、Python、OS、sys.executable、sys.argv、__name__、__file__、get_start_method()、launcher を保存します。
_check_not_importing_main の直前にある最上位 application frame が、child の import 中に process を作った経路を示します。
2. import work と entry work を分ける
definition、constant、import-safe setup は module scope に残せます。Pool、Process、Manager、ProcessPoolExecutor と worker を作る library call を main() に移し、__main__ guard からだけ呼びます。
entry module が import 時に helper を呼ぶなら helper 内の guard は遅すぎます。worker target は importable と picklable のため module scope に置きます。
3. start method を実測
Windows は spawn、現代 macOS も spawn が既定です。Python 3.14 では対応 POSIX の既定が fork から forkserver に変わり、upgrade 後に recursive import が表面化します。
エラーを隠すため fork を強制しません。必要なら get_context を application boundary で使い、imported module の深部で global method を変えません。
4. frozen app と third-party pool を分岐
通常 interpreter では freeze_support を省略できます。PyInstaller は同じ executable を child として起動するため override し、guarded entry で呼びます。import が先に multiprocessing や GUI を開始する場合だけ前へ移します。
traceback が library に入る場合、n_jobs、workers、processes が pool を作るか確認します。single worker は診断であり、parallelism 復帰後も entry は安全に import できる必要があります。
5. 同一 launcher で acceptance test
古い process tree を終了し、同じ launcher と environment で fresh run します。guard は parent のみ、worker target は children のみ、output は一回、終了後 orphan なしを確認します。
traceback、launcher、start method、call chain、code movement、fresh result を一つの記録にし、source と packaged の両方を出す場合は双方をテストします。
