🤖 New build scheduled with the buildbot fleet by@ericsnowcurrently for commitccc135c 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F133957%2Fmerge

If you want to schedule another build, you need to add the🔨 test-with-buildbots label again.

Thewasm32-wasi Non-Debug buildbot seems to be unused on merged commits and out of order on PRs. For example:https://buildbot.python.org/#/builders/1373/builds/507

Is the following usage invalid?

INITIALIZER_STATUS='uninitialized'definit(x):globalINITIALIZER_STATUSINITIALIZER_STATUS=xINITIALIZER_STATUS# for nowdefget_init_status():returnINITIALIZER_STATUSif__name__=="__main__":fromconcurrent.futuresimportInterpreterPoolExecutorexe=InterpreterPoolExecutor(initializer=init,initargs=('initialized',))fut=exe.submit(get_init_status)assertfut.result()=='initialized'# failsexe.shutdown(wait=True)assertINITIALIZER_STATUS=='uninitialized'

I guess the failure case in my previous comment can be resolved if therunpy_run_path is called only once for__main__ by using/keepingctx->main.cached->loaded or something across xi-sessions without being replaced. (My experiment was just putting a static local PyObject* var here ignoring the leak.)

FWIW, I haven't been able to reproduce the failures locally. It certainly is consistent across all the CI workers though.

Well, I figured out the problem. ApparentlyThreadPoolExecutor only starts new workers if there aren't any idle ones (and max_workers hasn't been reached), which is normally reasonable.

However, when a task is submitted, there's a narrow window from the time the task is queued up to when a worker picks up the job. If a second task is submitted and the code reachesThreadPoolExecutor._adjust_thread_count() before the worker created for the first task picks it up then a second worker will not be started in response to the secondsubmit() call.

The new test (test_blocking), which was hanging, was written with the assumption that there would be one worker for each task. This lead to an effective deadlock when there were fewer workers started. Asnoted by@neonene, the same situation was reachable by restricting the number of workers.

The solution was to unblock the tasks that did get picked up by workers, so they could finish and the workers could pick up the remaining queued tasks.

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

GH-135695 is a backport of this pull request to the3.14 branch.