GeezerVison

All commit authors signed the Contributor License Agreement.

Could we remove the shutdown-only PID notification instead of adding a drain loop?

I think that's the better solution and it looks correct to me. However, I'm not familiar with multiprocessing internals either.

Gentle ping for review @gpshead

I got GPT Sol to help me review this.

The current patch looks ready to merge. Removing the shutdown-only PID write directly eliminates the deadlock: the manager has stopped draining results and is joining workers, so those writes can block forever. The integer-PID consumer was removed in #109906; worker recycling still uses _ResultItem.exit_pid and is unchanged.

We found no new regression mechanism for multithreaded callers, shutdown modes, or worker failure handling. The full test_concurrent_futures suite passed locally on Linux. Restoring just the deleted write made the new regression test fail as expected under fork, forkserver, and spawn. Additional tests with threaded callers, large results, cancellation, and worker recycling also passed.

One non-blocking test caveat: Windows skips the _wlock synchronization, so deterministic reproduction is not guaranteed there.

I also checked whether removing the worker's exit-time result_queue.put(os.getpid()) could break third-party code on 3.14 or 3.15.

I searched the sources and upstream test repos of 33 popular packages (the snake_pit set: numpy, pandas, cython, pytest, django, sqlalchemy, uvloop, lxml, sympy, sphinx, etc.) for ProcessPoolExecutor, concurrent.futures.process, _ResultItem, _ExecutorManagerThread, _process_worker and result_queue. Users found:

• cython: Cythonize.py, Dependencies.py (with initializer=), runtests.py (max_tasks_per_child on GraalPy)
• numpy: test_multiprocessing.py (spawn context, submit)
• uvloop: tests/test_executors.py (run_in_executor)
• pytest: testing/test_reports.py (exception chaining via submit().result())
• lxml: download_artefacts.py (helper script)

All of these use only the public API. None of them reads _result_queue, subclasses the manager thread or depends on what goes through the result pipe.

Behaviour analysis: On 3.14, 3.15 and main, the only place the exit sentinel (None) is sent to workers is shutdown_workers(). That runs from join_executor_internals(), after the manager loop has stopped reading result_queue. So the PID written on exit was never consumed. If the manager loop had ever received one, process_result_item() would have failed on result_item.work_id. The "wake up queue management thread" comment dates from older versions that had an isinstance(result_item, int) branch, which no longer exists. During shutdown, worker exit is observed via p.join() and the process sentinels. The max_tasks_per_child exit path (exit_pid in _ResultItem) is unchanged.

The only behaviour change is that a worker no longer writes to the result pipe on its way out, so it can no longer block there. That is the deadlock this PR fixes.

Backporting: The process.py change applies cleanly to 3.14 and 3.15. The test applies cleanly to 3.15 and needs a minor manual merge on 3.14.

Conclusion: this seems to have a low risk of breaking existing code.