Emscripten event loop?

[hoodmane]

I think it would be helpful for the wasm/emscripten ecosystem to have an event loop as part of CPython. For example, recently we added Emscripten to the PyO3 CI PyO3/pyo3#2436. The asyncio tests have to be xfailed because there is no event loop. I would be willing to contribute one if there is interest.

The biggest drawback is that asyncio.run_until_complete and similar blocking APIs don't work, so it's different enough that many tests may not just work. On the other hand, I think that Pyodide's event loop has proven to be a very important feature.

@tiran @brettcannon

[brettcannon]

So are you asking for asyncio to gain an emscripten-based event loop? What would that look like? Would it require exposing JS-level hooks to tie into the JS event loop? If so, how would that operate since I thought there wasn't a desire to bring in js into the stdlib since it's so opinionated and tied to Pyodide?

And I assume such a loop could live on PyPI without issue, so having such a thing in the stdlib is a "nice to have" more than a "technically not possible any other way"?

[hoodmane]

If so, how would that operate since I thought there wasn't a desire to bring in js into the stdlib since it's so opinionated and tied to Pyodide?

I would rewrite the Pyodide event to avoid from js import ___. It is not intrinsically needed but it is convenient.

And I assume such a loop could live on PyPI without issue, so having such a thing in the stdlib is a "nice to have" more than a "technically not possible any other way"?

Without Pyodide, it might be difficult to dynamically link the event loop. If emscripten_set_timeout doesn't get dead code eliminated, it may be possible, but I'm not entirely sure how to generate the closure for the argument. If ctypes is included then it should be easy, but a stripped down build may not include that.

This is a convenience thing but it may make the difference in terms of complexity to be able to run stuff in CI: the non-asyncio PyO3 tests work only using the standard library. The async tests assume the standard library will contain a working event loop. To get to loading wheels from PyPI adds a significant amount of complexity beyond "just link libpython.a". It's desirable to keep CI builds simple and probably rather than pulling in enough stuff to load a wheel it would be better to xfail async tests.

[hoodmane]

I guess because PyO3 is statically linked I could make an event loop in a separate repo, clone it, and add it to Setup.local.

[brettcannon]

My key concern is Empscripten/WASI isn't even a tier 3 language for CPython, let alone something like a tier 2 language where it starts to make sense to try and get a WASM-based event loop working for the platform. And with the asyncio test suite being notoriously flaky, adding anything there makes me worry. 😅

[tiran]

I have good news and bad news for you. The asyncio tests are not working on wasm32-emscripten anyway because socket.socketpair() is not working yet. asyncio tests require a working bi-directional pipe.

[kumaraditya303]

I think it is too early for an emscripten event loop in stdlib. Since emscripten does not support some(most?) of the socket functions, it would require a lot of if emscripten raise exception else continue and lot of complexity in test suite.

As Brett said, emscripten is not even a tier 3 platform so adding it to stdlib is unlikely, however you can work on it in a fork.
You can discuss this on discourse, so closing.