Python 3.15rc2 on macos x86_64 creates additional thread at startup

[bdarnell]

Bug report

Bug description:

Python 3.15rc2 (from the official installer on macos x86_64 (rosetta emulation, not confirmed for native x86 hardware) creates a second thread at startup, causing any attempt to use os.fork with deprecation warnings enabled to emit a warning. This does not occur on arm64 builds or on non-macos platforms (tested linux and windows, x86 and arm).

Reproduction steps

1. Install python 3.15rc2 from https://www.python.org/downloads/release/python-3150rc2. Tested environment: M1 Macbook Pro running macos 26.6.2. Also observed on whatever github's macos-15 runner gives you.
2. Run arch -arm64 python3.15 -Werror -c 'import os; os.fork()'. See that no output is produced.
3. Run arch -x86_64 python3.15 -Werror -c 'import os; os.fork()'. It prints

Traceback (most recent call last):
  File "<string>", line 1, in <module>
    import os; os.fork()
               ~~~~~~~^^
DeprecationWarning: This process (pid=98584) is multi-threaded, use of fork() may lead to deadlocks in the child.

Expected results

A freshly started interpreter should not be running more than one thread and should be able to fork without warning.

CPython versions tested on:

3.15

Operating systems tested on:

macOS

[bdarnell]

The offending thread is not a python-managed thread: len(sys._current_frames()) is 1 regardless of architecture. os.fork uses a different OS API to count threads, and this one reports 2 on x86_64.

[ned-deily]

Thank you for the report. Here are a few initial observations.

This DeprecationWarning is not new to 3.15. You can reproduce the same warning with python.org universal2 installers going back to 3.12 when #100228 introduced this check for os.fork with multiple threads. However, note that there was a bug in that feature that skipped the deprecation message when using -Werror; that bug is fixed in 3.15 by #135427 and that fix was deliberately not backported to earlier releases to avoid potential compatibility issues. So to reproduce the warning on 3.12 through 3.14 systems, you need to not use the -Werror option.

The warning does not appear when the test is run on native Mac Intel systems using the same python.org installers. So it would appear it does have something to do with Rosetta 2 emulation, something we don't regularly test.

I also verified that it does not appear to have anything to do with CPython's framework build app bundle launcher; the warning appears in the same cases when directly invoking the Python executable, for example:

arch -x86_64 /Library/Frameworks/Python.framework/Versions/3.14/Resources/Python.app/Contents/MacOS/Python -c 'import os; os.fork()'

and also when using the Rosetta-forcing convenience executable, for example:

python3.13-intel64 -c 'import os; os.fork()'

I also was able to reproduce the same behaviors when using MacPorts universal builds of Python 13, 14, and 15.

Based on all this, this doesn't seem to warrant release blocker status. It should be investigated further but it may turn out to be something inherent to Rosetta 2 usage. But it does not seem to be an issue for running natively on either Apple Silicon or Intel Macs.

[ned-deily]

• @gpshead @python/macos-team

[bdarnell]

This DeprecationWarning is not new to 3.15. You can reproduce the same warning with python.org universal2 installers going back to 3.12 when #100228 introduced this check for os.fork with multiple threads. However, note that there was a bug in that feature that skipped the deprecation message when using -Werror; that bug is fixed in 3.15 by #135427 and that fix was deliberately not backported to earlier releases to avoid potential compatibility issues. So to reproduce the warning on 3.12 through 3.14 systems, you need to not use the -Werror option.

Ah, I didn't know that. It just started showing up in my CI configuration with 3.15. I agree that it's not a release blocker (I'd probably agree with that even if the behavior were new in 3.15, since it's limited to an incorrect deprecation warning).

It does appear to be rosetta-related. It turns out that rosetta creates a thread named com.apple.rosetta.exceptionserver. I've found some references to this online but no official documentation.