[Bug]: Rosetta for Linux: fork() interrupts libc.sleep() in another thread with EINTR #2352

I have done the following

• I have searched the existing issues
• If possible, I've reproduced the issue using the 'main' branch of this project

Steps to reproduce

1. Start a Linux amd64 container with Rosetta enabled.
2. Copy the attached rosetta_sleep_repro.py into the container as /tmp/rosetta_sleep_repro.py. The script uses only Python's standard library and the system C runtime; no compilation or application shared library is needed.
3. Run the control inside the container:

python3 /tmp/rosetta_sleep_repro.py

4. Run the reproduction, which calls os.fork() in the main thread while a worker thread is inside libc.sleep(3):

python3 /tmp/rosetta_sleep_repro.py fork

The child sleeps for one second before exiting, so its exit occurs after the worker's premature return. Reproduced in two running amd64/Rosetta containers.

rosetta_sleep_repro.py

Problem description

Expected behavior

The worker should complete its 3-second sleep when the application has installed no signal handler or explicitly sent a signal to interrupt it. A fork in another thread should not expose an interruption caused by the translator's internal thread coordination.

Actual behavior

Without fork:

libc.sleep(3): elapsed=3.006681 remaining=0 errno=0

With fork:

libc.sleep(3): elapsed=0.106471 remaining=2 errno=4
child reaped after 1.007389 seconds

errno=4 is EINTR. The sleep returns almost immediately after fork begins, well before the child exits.

A standalone C pthread reproducer exhibits the same behavior. In the same container and Linux kernel, a direct SYS_clock_nanosleep comparison also fails under x86_64/Rosetta (0.105 seconds, EINTR) and completes normally with a native ARM64 binary (3.002 seconds). This points to Rosetta's handling of fork and internal signals.

Workaround tested

Using CLOCK_MONOTONIC with an absolute deadline and retrying clock_nanosleep on EINTR completes the full wait. Python time.sleep(3) also completes the full wait, but direct calls to libc.sleep in application libraries remain affected.

Please investigate whether Rosetta's internal fork coordination can leak EINTR into another translated thread's sleep syscall.

Environment

- Host: Apple M4 Pro (Apple Silicon)
- OS: macOS 26.6.2 (25G83)
- Xcode: Command Line Tools selected; full Xcode not used
- Container: CLI 1.1.0 (release, commit 5973b9c)
- Guest: Linux 6.18.15, linux/amd64 with Rosetta enabled, 2 CPUs, 2048 MB RAM
- Guest libc: GNU libc 2.38
- Guest Python: 3.11.6
- Reproduction date: October 5, 2026

Code of Conduct

• I agree to follow this project's Code of Conduct