Avoid joining parent thread pools in forked children

[Taegyun Kim (taegyunkim)]

Description

Record the process ID that creates each thread pool. If the copied pool is
destroyed in a forked child, abandon its inherited low-level state instead of
touching synchronization objects or joining thread handles owned by the parent.

Add a Linux regression test that creates a thread pool, forks, destroys the
copied pool in the child, and verifies that the child exits normally.

This does not make inherited thread pools usable after fork.

Motivation and Context

Destroying an ONNX Runtime InferenceSession inherited across fork can terminate
the child with SIGSEGV in pthread_join because the stored worker handles belong
to the parent process.

The issue is reproducible with the CPU Execution Provider and does not require
inference, CUDA, or a particular model. Applications should create sessions
after fork, but accidental cleanup of inherited state should not crash.

Forking a multithreaded process is inherently unsafe. CPython documents this
limitation for os.fork() and emits a DeprecationWarning when it detects
multiple threads. Applications should avoid carrying a live ONNX Runtime
session across a fork boundary.

At the same time, prefork process models are common in Python web deployments.
For example, Gunicorn forks worker processes from a master process. If
application preloading or module-level initialization creates an
InferenceSession in the master, ONNX Runtime's native worker threads are
created before Gunicorn forks. The resulting session and thread handles are
then inherited by each worker.

The application-level fix is to create each InferenceSession after the final
fork, such as during worker initialization. However, library-side defensive
handling is still useful. Python object finalization can destroy an accidentally
inherited session during worker shutdown, and that cleanup should not attempt
to synchronize with or join threads owned by the parent process.

This change does not make inherited sessions fork-safe or endorse using them in
a child. It only recognizes that the copied thread pool cannot be safely
destroyed there and prevents that unsupported usage from becoming a process
crash during cleanup.

References

• CPython os.fork() warning
• Gunicorn pre-fork worker model

Reproducer

# /// script
# requires-python = "==3.14.6"
# dependencies = [
#   "onnxruntime==1.28.0",
# ]
# ///

import base64
import os
import signal

import onnxruntime as ort


# A 65-byte ONNX model containing one Identity node: float[1] -> float[1].
MODEL = base64.b64decode(
    "CAo6NwoQCgF4EgF5IghJZGVudGl0eRIBZ1oPCgF4EgoKCAgBEgQKAggB"
    "Yg8KAXkSCgoICAESBAoCCAFCBAoAEBU="
)

session = ort.InferenceSession(MODEL, providers=["CPUExecutionProvider"])

pid = os.fork()
if pid == 0:
    # This destroys the copy of the session inherited from the parent.
    del session
    os._exit(0)

_, status = os.waitpid(pid, 0)

if os.WIFSIGNALED(status):
    child_signal = signal.Signals(os.WTERMSIG(status)).name
    print(f"child terminated by {child_signal}")
    raise SystemExit(1)

print(f"child exited with status {os.WEXITSTATUS(status)}")

Run:

uv run --python 3.14.6 repro.py

Output with ONNX Runtime 1.28.0:

child terminated by SIGSEGV

Confirmed environments:

• Linux x86_64: reproduced on Ubuntu 22.04, glibc 2.35, CPython 3.13 and 3.14, ONNX Runtime 1.26.0 through 1.28.0.
• Linux aarch64: observed in production on Debian 12, glibc 2.36, CPython 3.14.6, ONNX Runtime 1.26.0.

The same failure was reproduced with ONNX Runtime 1.26.0, 1.27.0, and 1.28.0. No inference, CUDA provider, onnx package, or external model file is required.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Taegyun Kim (taegyunkim)]

@microsoft-github-policy-service agree [company="DataDog"]

I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

[Taegyun Kim (taegyunkim)]

@microsoft-github-policy-service agree company="Datadog"

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.