ports/webassembly: Add cooperative VM yield to the JS event loop. - #19427

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.51%. Comparing base (13303f8) to head (0490b6f).
⚠️ Report is 183 commits behind head on master.

@@           Coverage Diff           @@
##           master   #19427   +/-   ##
=======================================
  Coverage   98.51%   98.51%           
=======================================
  Files         177      177           
  Lines       22927    22992   +65     
=======================================
+ Hits        22586    22651   +65     
  Misses        341      341           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

Code size report:

Reference:  tests/basics: Update t-string test cases for unicode. [f67ab9e]
Comparison: webassembly: Add a regression test for mid-execution Ctrl-C. [merge of 0490b6f]
  mpy-cross:    +0 +0.000% 
   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
      esp32:    +0 +0.000% ESP32_GENERIC
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +0 +0.000% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

This is possibly of interest to @LeaNumworks upon whose work I have no doubt been building.

Right now the Numworks simulator has A Bad Time if you're so bold as to use a loop. This is exactly the sort of behaviour this PR fixes successfully for our own simulator.

And since a picture - or a live demo - is worth a thousand words: https://gadgetoid.github.io/upyweb/

Thanks for tagging me, I forwarded it to our team!

Good to know you've been getting some use out of this webassembly port!

It's on my list to look into JSPI. But the first thing there is to see how Pyodide use it and what their user-facing API is with JSPI enabled. See eg https://blog.pyodide.org/posts/jspi/

They use the same general shape but they have wildly different ambitions to where I was going.

I'm maintaining support for Asyncify (even if it's terribly, terribly slow) and adding JSPI on top, both supporting the ability to cooperatively yield to the browser with emscripten_sleep one blocking I/O call at a time.

Pyodide is (afaict) all-in on JSPI and offers real asyncio (implied stack switching between multiple MicroPython tasks... dark magic) and reentrant run_sync().

As for API surface specifically:

Notably there is a lot of overlap, I was solving a bunch of problems (quite unwittingly so) that Pyodide had already folded into their asyncio-first pattern.

That said I think Pyodide leans into asyncio and still doesn't solve the problem I was targeting; being able to run while True: without Python never yielding to the caller. Fixing this gives us a single, cooperative MicroPython engine that lets us simulate MicroPython-based devices on the web (and do all the previous stuff we could do with asyncio) that an unwitting user can't just lock up with two lines of code. (Interestingly even Pyodide users want to do this pyodide/pyodide#1219)

Looks like what they offer is trueasyncio running Python from multiple callers- potentially very useful for something that uses the Python language as an engine to drive scriptable behaviour across a whole, conventional web app... if this is where you want to head with MicroPython then our goals are misaligned (read: completely tangental), but it's not a bad outcome to target. Right now I don't think we have any meaningful support for multiple interpreters on any platform? Though it's been tried: https://github.com/orgs/micropython/discussions/18180 (Pyodide uses switchable greenlets so it's still one engine)

I think we want both approaches, but the road to what Pyodide is doing seems much longer and more involved than getting what we have playing nicer. But also I appreciate you don't want to commit further to an API surface that's likely to dramatically change.

I've walked what's presented here toward Pyodide by borrowing their can_run_sync() and run_sync() and adapting jsfetch to use it. The internal mp_js_can_suspend() I had arrived at is functionally can_run_sync() (because the sync call out to a JS Promise needs to safely suspend MicroPython) so you can:

import js
from jsffi import run_sync, can_run_sync

if can_run_sync():
    resp = run_sync(js.fetch("https://example.com/data.json"))
    data = run_sync(resp.json())          # blocking, no await needed
    print(data.title)

run_sync(js.Promise.resolve(42))

This is really useful for burying async calls into synchronous libraries- ie: where you'd normally expect a real device to do a blocking call (unless you're going significantly out of your way to work with asyncio, select, etc)

I always use run_python_async() as the entry point, and can still just do it the old async-in-everything way:

import js
import asyncio

async def main():
    resp = await js.fetch("http://127.0.0.1:8000/")
    text = await resp.text()
    print(text)

await main()

Suffice to say run_sync is one part of Pyodide where we agree.

Still kinda marvellous that any of this even works - https://gadgetoid.github.io/upyweb/ui.html

I've dropped _jsfetch (redundant) and @micropython.native noop (out of scope) from this PR since it's already a huge burden for anyone to look over and test.

I have applied some commit surgery to include an extra function to the asyncify-fast build (which unbreaks some file IO cases), since I'm keen to use this in production (it's significantly faster, but will likely encounter issues until all possible code paths are exercised and the necessary ones opted-in to asyncify's bloat). Note: I'm still having trouble with the fast build.

I think this is walking slowly toward a serious proposal. Notably half of the files touched by this PR are tests, but there are still a huge number of changes to main.c and other spicy areas.

Edit: After sinking far too much time into trying to catch all the edge cases in asyncify-fast for my purposes I'm tempted to drop it, though as just vanilla MicroPython it should be fine and may be of use to someone? Another, separate PR later perhaps.

Edit: Latest push catches a regression in Ctrl+C handling and adds a test to guard for it. Otherwise it is mostly just non-functional cleanup to bring this change more in compliance with existing practises.

After sinking far too much time into trying to catch all the edge cases in asyncify-fast for my purposes I'm tempted to drop it,

Dropping it sounds good to me! I'd go even further and suggest to remove all ASYNCIFY support and just go for JSPI. ASYNCIFY won't be a viable long term option, it's short term if anything.

JSPI is currently supported in Chrome, Edge and Opera: https://caniuse.com/wf-wasm-jspi

I'm hoping that changes quickly because Asyncify is slow and unwieldy and indeed it would really simplify this PR.

It's useful as a short-term fallback, though once you start adding WebSerial code deployment (which we're considering for our simulator) you're shackled to Chrome anyway.

Hi 👋

Just adding a note of thanks for JSPI efforts and for dropping asyncify. My use of MicroPython in the browser is as a browser based runtime for doing, er, browser-y things via the FFI. I also want to emphasise how important it is that MicroPython's JSPI support has a public API that mirror's Pyodide's implementation. It means Python runtimes can be easily slotted in/out as need arises without having to change project code. Of further note is also that I believe JSPI support is coming to Firefox (it's being tracked via this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1897981). I start a new gig tomorrow so my spare cycles are going to be limited in the coming few weeks, but if you want someone to test things I'm more than happy to be that crash test dummy. 😄 👍 🚀

if you want someone to test things I'm more than happy to be that crash test dummy

Testing- yes please. But - vitally more important - your input as another user of MicroPython WASM. I'm pretty new to this corner of the codebase and made changes to suit my needs first and foremost, then tried to shape them to be suitable for upstream second.

The points about Pyodide are particularly salient, and I agree. MicroPython reflects CPython. MicroPython WASM ought to reflect Pyodide.

Possible talking point along those lines - a Fetch API based mip?

May also be worth considering how we handle stuff like urllib and requests, which I currently vendor modified shims for- since they need a deep rewrite from using a raw socket, to just being a wrapper around Fetch.

Pyodide has experimental support for sockets when running under node - https://pyodide.org/en/stable/usage/socket.html - which, if it goes anywhere, would mean we'd have two classes of networking library:

1. Ones which need a socket and will only work in Node
2. Ones which can be shimmed by Fetch and might need a WASM-only counterpart (And then CORS will block your requests anyway 😆)

The one place I think we differ - for my needs in particular - is the cooperative yield to handle fully synchronous code (while True: do stuff) gracefully. That could easily be a variant/build option.

Anyway TLDR; help shaping this would be appreciated.

👋 Apologies for my tardy response time. I started a new gig this week and I've been snowed under with on-boarding activities.

So my use for WASM MicroPython is exclusively within the browser. It turns out, if you want Pythonic things in the browser, MicroPython gives you what you need in the blink of an eye. This is in contrast to Pyodide, which brings everything but the kitchen sink, and is relatively slow to start. Both have a place - Pyodide brings the Python ecosystem to the browser, MicroPython brings "Pythonic" to browser based development. They complement each other and I intend to evolve things on from PyScript to a project I'm calling "browser friendly Python".

Blocking calls in Python in the browser and the whole sync/async dichotomy have been a pain point. In PyScript we used web workers, atomics and shared-array-buffer, to simulate blocking, but this came at a price of complexity in our code, performance trade-offs, lots of deeply technical research and obscure server configuration related to COOP/COEP headers that are often hard to control and even more difficult to make sense of. Definitely not ideal and a set of work-arounds on top of work-arounds. With the arrival of JSPI pretty much 99% of those problems go away, and it means browser friendly Python can be significantly simpler and easier to use than PyScript ever was.

This is why I'm interested in this work and willing to participate as best I can to help get this to land. FWIW @dpgeorge and I have chatted about this over the past three months or so as something affirmative to the WASM build of MicroPython. Damien also tells me there are known locations in MicroPython where the interpreter can yield to the browser's event loop so while True: pass can work without blocking the main thread.

Anyway... this is a bit brain-dumpy... but I hope you see my view of this particular mountain, and I hope we can compare notes so we arrive at a nice, simple yet effective and flexible solution for JSPI / MicroPython. 👍

Morning folks. 🌞

Over the weekend (and just recently with fresh eyes), I did a quick analysis (with the help of Claude) of the current state of play based on this PR. Rather than clutter up this PR, I've stuck it all in this gist which contains the LLM's initial draft, heavily edited and changed by me: https://gist.github.com/ntoll/88634f27175c585729e619287d008871

@dpgeorge @Gadgetoid - please take a read. It's relatively short but VERY specific as a proposal to land just JSPI, based on the initial work you (Phil) have already done.

My suggestion is this report leads to a new PR for JSPI support only.

What I expect is some discussion and questions, but the core thing you need to know is LLM estimates the PR to be around 200 LoC (i.e. relatively small). Now, knowing how Damo works, it should be relatively trivial to create this PR as a "to-throw-away" PoC. What I expect will really happen is Damo will roll his own solution 😉, so this is simply an exercise in creating a coherent, simple and easy to understand context, with some working code, from which Damien can trivially build a solution to his liking.

Please let me know what you think. Happy to answer questions. Totally understand if the answer is "nope". FWIW - JSPI is the missing link for my BFP project to land, so I have skin in this game. 🤗

If you're willing to land that JSPI PR I'm happy to defer. My specific use case (https://try.badgewa.re) wont serve as a very good test for it.

I've been meaning to come back and prune this PR, but haven't had the time. Appreciate your insight!

See #19594, and thanks for getting this going @Gadgetoid 🤗. Without your initial work none of this could have been done so quickly.

@dpgeorge I imagine you'll have opinions about the implementation in #19594 - please feel free to change anything. 💪

This is the final piece in the BFP jigsaw puzzle and, once landed/released, will allow me to do an alpha release of BFP in a couple of weeks once I've finished off the other 90% of work that needs completing. 😉