-
Story
-
Resolution: Done
-
Critical
-
None
-
None
-
None
-
3
-
False
-
-
False
-
rhos-ops-platform-services-pidone
-
-
-
Sprint 7, Sprint 8, Sprint 9, Sprint 10
-
4
-
Important
Goal: Provide a single utility module exposing get_spawn_context() and get_spawn_pool() so every future multiprocessing call inside oslo.service defaults to the spawn start method, eliminating fork-inherited lock deadlocks highlighted in the PythonSpeed article.
Acceptance Criteria:
- Verify new module oslo_service/_multiprocessing.py exists and is imported nowhere at import-time (no side-effects).
- Verify get_spawn_context().get_start_method() returns "spawn".
- Verify get_spawn_pool() returns a multiprocessing.pool.Pool created with spawn context.
- Verify Sphinx docstring explains the deadlock scenario and rationale.
- All existing unit tests still pass.
Additional Details:
See https://pythonspeed.com/articles/python-multiprocessing/ and video explanation at https://youtu.be/RIc-Tut95YM?t=185.
- blocks
-
OSPRH-17942 [fork vs multiprocessing] 4 - Update threadgroup.py to use spawn in process-spawning helpers
-
- Backlog
-
-
OSPRH-17943 [fork vs multiprocessing] 5 - Add non-deadlock regression tests & CI job
-
- Backlog
-
-
OSPRH-17944 [fork vs multiprocessing] 6 - Harden logging configuration against fork-related deadlocks
-
- Backlog
-
-
OSPRH-17945 [fork vs multiprocessing] 7 - Add internal documentation & release notes for spawn migration
-
- Backlog
-
-
OSPRH-17938 [fork vs multiprocessing] 2 - Refactor service.py to use spawn-safe pools
-
- In Progress
-
-
OSPRH-17941 [fork vs multiprocessing] 3 - Refactor periodic_task.py for spawn-safe parallel tasks
-
- In Progress
-