no time.sleep() ... how to call js async code from python runtime ?

[amigrave]

I noticed that time.sleep() is a no op in the pyodide's cpython webassembly runtime. As cpython implements it using select.select()'s timeout, it's not really a surprise that it's not supported by pyodide.

That said I have to call a javascript function from the python runtime and the js function will do asynchronous stuff before being able to return the value. eg:

from js import my_async_javascript_function

I first tried to do polling but without time.sleep() it's not doable.

How can I handle this properly with pyodide ? Through Promise ? async/await ? ... I could not find a clue for this, any hint would be appreciated.

Thanks

[mdboom]

This is definitely something on the roadmap for which there is currently no good solution.

The best I can recommend is to write a wrapper around the Javascript function (in Javascript) that takes a callback function as an argument, and then calls the callback when the async function is complete. From Python, you can then pass a Python function in as an argument, and Python will continue running from there.

An alternative (if you really want to do polling) is to use Javascript's window.setTimeout from Python, and poll in the callback function.

Both of these options have to delegate control to a callback function, however, which is why neither is a complete solution.

[amigrave]

@mdboom thanks for the advise ! Shall I keep the issue opened ?

[mdboom]

I think it's worth keeping it open -- we should have a better solution for this, or at least better documentation.

[akloster]

I think the best solution would be an asyncio implementation using the Web APIs. Let's call it webaio. It would provide an event loop with timers, XMLHttpRequests, DOM interaction and probably others.

[daicoden]

Poking around this....

Looks like upgrading pyodide to work on llvm #476 would enable asyncify's emscripten_sleep.

https://kripken.github.io/blog/wasm/2019/07/16/asyncify.html

Is the work to LLVM important, or nice to have?

[rth]

So asyncify apparently has around 50% performance cost which could be a lot for default builds. From, https://emscripten.org/docs/porting/asyncify.html#optimizing

Asyncify adds overhead, both code size and slowness, because it instruments code to allow unwinding and rewinding. That overhead is usually not extreme, something like 50% or so.

but we won't find out how much it would be for pyodide until we try.

In any case, updating to the LLVM upstream emscripten backend it is essential, and should unblock a number of issues. It tuned out to be not easy so far. I'll comment in #476 with a status update.

[pmp-p]

That overhead is usually not extreme, something like 50% or so.

Sadly that is for normal programs where only a few blocking calls need to be async. Also i suspect these numbers are for programs that don't yield from their main loop often ( eg no immediate drawing/url opening and only non recursive calculations ).

In an interpreter VM : the whole path to - and including - the bytecode loop must be "asyncified" because it can block (eg call sleep) anytime.

but we won't find out how much it would be for pyodide until we try.

With a pre-emptible stackless python interpreter which allows aio_suspend and does not have to record the stack, only instruction pointers, the worst loss is 2-3x, while generic asyncify was around 10x ( ie 20x slower than native).

[pmp-p]

@amigrave problem is linked to the fact that time.sleep() in cpython is just an idle wait, it allows OS to pause the Python thread, and process IO meanwhile.

If you are not in a worker thread on wasm you can't do that way : that means exiting cPython loop to give hand to javascript host

Doing that will unwind the stack and using setjmp was no help last time i tried.

an alternative solution for cpython in its current state - without using worker - is to use asyncio for everything that you can predict will block in your python code.

[sconover]

If you are not in a worker thread on wasm you can't do that way : that means exiting cPython loop to give hand to javascript host

@pmp-p What would your approach be to implementing sleep via a webworker? Maybe I'm being dense but the only solution that comes to mind is a spinlock, but I assume that such a lock would also prevent communication via onmessage/postMessage...

[pmp-p]

@sconover i'm sorry i have no real clear idea for that : web workers/asyncify are outside of my experimentation field, my far goal is multiple wasm/wasi interpreters loops running as uniprocessor couroutines on single hardware thread each.

Looking at pyodide from that point of view ( not web centric, and refusing threading ) I would pick up stackless python code base instead of cpython and make it pre-emptible in ceval.c, so any blocking bytecode block could yield to host via the vm eval loop via aio_suspend instead of python loop.

But that's kinda dreaming so to summarize what is real at the moment :

my wapy python interpreter model has two vm :
1 - original one with C-stack full speed for asyncio use only.
2 - mine is a C-assembly coroutine built upon pfalcon stackless model with as much registers as recursion depth and is 2x slower than async ie 4-7x slower than native cpython running in a thread.
when you want IO/timers , you launch io request on the async loop, call aio_suspend() until your IO is serviced or timeout. ( here is sleep in wapy https://wyz.fr/0L-andin )

The asyncio loop gives access to timers and io completion various locks, but it is running interleaved with the sync loop which gives hand back to js with the aio_suspend() function

so it's not spinlock + busy looping. but more a python vm loop as a C coroutine which resume instead of yielding depending on locks conditions.

To achieve that on cpython without core changes, I think you could POC implementing a Python VM in the python asyncio loop to run the sync bytecode ( there are some python-in-python vm around but not sure if any of those were written with async in mind )

i think such a POC would be insightfull for people who don't get fully why the actual cpython loop vm model is becoming a real blocker for some domains of application (including but not limited to real time and web/wasi).