Thanks @vsajip for the PR 🌮🎉.. I'm working now to backport this PR to: 3.12.
🐍🍒⛏🤖

Thanks @vsajip for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖

GH-120071 is a backport of this pull request to the 3.12 branch.

GH-120072 is a backport of this pull request to the 3.13 branch.

@vsajip: It looks like this PR didn't completely fix the issue. The iOS buildbot has been failing for the last few hours because of some iOS version issue – hopefully @freakboy3742 can fix that when he has a chance. But before that, it was failing for the previous 9 days because a logging test was still trying to use multiprocessing.

@mhsmith That error looks like Xcode has auto-updated itself, but hasn't installed an updated simulator. I've just logged into the machine and completed the install process.

What's weird is that the buildbot interface isn't raising alerts, and (at least for me), the link you've provided (which has previously worked for me), is showing no builds...

Update: It was just very slow. I'm seeing the builds now. But there hasn't been any notifications...

Update 2: There was a notification, but it only notified the first build failure, and I missed that notification.

Do you know why the previous fix (import_helper.import_module('_multiprocessing')) didn't work? Especially as the original error on iOS referred to the inability to import _multiprocessing.

It does work (although requires_subprocess is a slightly more common way to capture the requirement in the rest of the code base). The test failure we're currently seeing is a completely separate test to the one this PR is modifying. That test is currently only guarded on needing threads, but has an implicit dependency on the subprocess capabilities of multiprocessing.

OK, but requires_subprocess basically just relies on sys.platform values, right? Conceivably _multiprocessing could be unavailable in other scenarios?

Yes, requires_subprocess is based entirely on sys.platform.

I guess it's possible you might be on a platform where the platform supports subprocesses, but _multiprocessing hasn't been compiled; but given multiprocessing's only real dependency is subprocesses, it's seems highly unlikely. And, in this case, the problematic test doesn't use _multiprocessing at all - it's failing because the pure Python parts of multiprocessing.