Fallbacks for threading-less environment?

[ryanking13]

Things to check first

• I have searched the existing issues and didn't find my feature already requested there

Feature description

I wonder if it would make sense for AnyIO functions that use threading in the background gets fallback to the single-threaded version when threading is not available.

For example, anyio.open_file currently uses aynio.to_thread.run_sync internally, and using it in threading-less environment such as WebAssembly fails with can't start new thread error.

Use case

I maintain Pyodide + WebAssembly/Emscripten platform in CPython. In WebAssembly environment, often threading is not available and codes that use threading runs into a runtime error.

Users of startlette and FastAPI were having issues porting their application to WebAssembly, as codes such as anyio.open_file or anyio.to_thread.run_sync requires threading support in the runtime environment.

Originally, I was discussing this issue in starlette (Kludex/starlette#3284), but I was wondering if this can be solved in AnyIO side, by providing threading-less fallbacks of those functions.

Of course, I understand that running everything including the I/O functions in the same thread means it will degrade the performance. But it would help users port their existing codes that use AnyIO without modification.

[davidbrochart]

I'd also like to have a solution built in AnyIO itself.
I have a project where Python runs in the browser using emscripten-forge, and for now I work around this issue using:

async def run_sync(callable, *args, **kwargs):
    return callable(*args)

import anyio.to_thread
anyio.to_thread.run_sync = run_sync

Of course this only works if the function to call in a thread is not long-running.

[tapetersen]

For a lot of cases (probably the majority, especially for starlette/fastapi) dispatching to a thread is only done for opportunistic event-loop unblocking for latency and performance. In these cases just substituting with a sync call will of course work but wouldn't this lead to potential deadlocks where the sync call's progress is dependent on a task in the event loop unlocking it?.

For the async file-api it should probably generally be fine but for general to_thread calls it wouldn't be hard to construct cases that only completes if the run_sync call actually frees up the event-loop for other tasks.

At the same time I can't directly come up with a "typical common case" that would run into it in a minute so it may be rare enough that just letting them just block may indeed work for a large amount of applications.

[ryanking13]

Yeah, at least starting with async file-api would be great for us. A direct aynio.to_thread.run_sync call can be replaced with sync calls in downstream project, but it is slightly tricky to replace anyio.open_file or other file IO apis.