Jens-G opened a new pull request, #3633: URL: https://github.com/apache/thrift/pull/3633
## Summary - `test/py/TestServer.py` shuts the `TProcessPoolServer` test flavor down via a `signal.alarm(4)` handler that terminates the worker processes and then calls `server.stop()`. - `TProcessPoolServer.serve()` blocks its main thread in `multiprocessing.Condition.wait()`. Since Python signal handlers run synchronously nested inside the interrupted thread, the handler reenters on the *same* thread that's parked in `wait()`. `stop()`'s `Condition.notify()` then blocks forever waiting for a wake acknowledgement that only the (now unreachable) interrupted `wait()` call could ever send — a permanent deadlock. - This reproduced deterministically (10/10 runs, both `fork` and `spawn` multiprocessing start methods) against the unmodified library, and matches a `lib-python-macos` CI job that hung until GitHub Actions' 6-hour ceiling (see #3632 for the accompanying CI timeout). - Fix: terminate the workers and exit the process directly (`os._exit(0)`) instead of coordinating through the `Condition`, since the process is being torn down anyway. Verified the fix with 30/30 clean exits (20x `spawn`, 10x `fork`) where the original code hung 15/15. - JIRA: THRIFT-6082 ## Test plan - [x] `python3 -m py_compile test/py/TestServer.py` - [x] `flake8` clean (project `.flake8` config) - [x] Isolated repro harness against the real `TProcessPoolServer`/`TestServer.py` shutdown logic: 15/15 hangs before the fix, 30/30 clean exits after - [ ] CI (`lib-python`, `lib-python-macos`) green on this PR Co-Authored-By: Claude Sonnet 5 <[email protected]> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
