PHP WASM: Compile PHP to WASI #290
Comments
|
What a great issue @eliot-akira, thank you so much for putting all this information together!
You're exactly right! I thought Asyncify was a JavaScript thing, but it seems like it's not. TIL! This certainly opens the door to supporting WASI. This would still be a challenge, though, unless we let Asyncify auto-wrap everything it wants to: #251 |
adamziel
added
[Type] Enhancement
|
The Python WASI demo shipped with code = '''
import os
import time
pid = os.fork()
if pid > 0:
print("I am parent process:")
print("Process ID:", os.getpid())
print("Child's process ID:", pid)
time.sleep(3)
print("Parent process is killed")
else:
print("I am child process:")
print("Process ID:", os.getpid())
print("Parent's process ID:", os.getppid())
time.sleep(3)
print("child process is killed")
'''
with open("process_test.py", "w") as file:
file.write(code)
import process_testNow, these demos ship an entire OS compiled to WASM and require more resources to run, but for something like a development environment that should be fine. I wonder whether the WASI shim can handle forking a process. If so, perhaps we could ditch emscripten, migrate to WASI entirely, and get more features with less patches. |
|
Container2Wasm demos are impressive but also too slow for any real-world use:
browser_wasi_shim is promising and its filesystem implementation looks much cleaner than the Emscripten's one, but it has important limitations:
On the upside, there were some explorations to support the WebAssembly Component Model. Either way, there's nothing actionable here today. |
|
It is possible that recent WASM runtimes support longjmp and exceptions which means we could potentially produce a standalone WASI now – this needs investigation: emscripten-core/emscripten#20484 I'm not sure what about async IO and fork |
|
https://github.com/bytecodealliance/jco/ is interesting:
|
|
Not sure how related or relevant to this issue, but here are some developments on the topic of WASM/WASI that I found interesting. It looks like the possibility of removing/replacing Asyncify is getting closer.
I was exploring an early prototype of Zig language playground, which compiles the Zig compiler (and language server) with Emscripten to run in the browser. It uses a fork of the WASI shim/polyfill mentioned upthread, bjorn3/browser_wasi_shim. I have an idea to fork this playground and integrate with the WASM-4 game engine, which has a tiny SDK for Zig, as a fun way to learn the language entirely in the browser without having to install the compiler locally. An interesting aspect of this is a workaround to set COOP and COEP headers to make A WASI shim for VSCode:
A WASI shim written in PHP:
A WASI runner for the web (@runno/wasi)
Going off topic, here and there I see people attempting to implement networking functionality in the browser..
This article you've probably seen already:
|
|
Such an amazing writeup, thank you so much for sharing all of that @eliot-akira – it's extremely useful! I'm especially wowed by the WASM runtime built in PHP :D cc @luisherranz
Playground used to be hosted on GH pages and it would probably "just work" there today, it doesn't use SharedArrayBuffers. |
|
Wasmer 5 runs on iOS! With a WASI build we could run WordPress in native apps without a webview. We could validate the idea with the VMLabs PHP WASI build. |
There was a pull request #113 that was exploring this direction, which was closed recently with a note to come back at a later time.
From what I understand, an advantage of compiling PHP to WASI is that it can be a standalone binary that runs without dependency on Node.js. I wanted to contribute a bit by gathering related links that I came across while studying about this topic.
In the WASI repo, there was an issue WebAssembly/WASI#490 asking about
setjmpsupport. It was closed with the following note:So the feature will be implemented eventually. That implies that any workaround solution is temporary, to be replaced/removed in the future.
In the meantime, a WebAssembly / WASI port of Ruby was developed, which gets around the limitation by emulating
setjmpandlongjmpwith Asyncify. I learned about it from these articles:Then someone re-purposed that
setjmppolyfill to integrate with PHP. Here's the as-yet-unmerged pull request:In parallel, another person from VMware started on an ambitious effort in the PHP repo itself.
Hopefully this issue can serve as reference when there's progress in any of the above.
The text was updated successfully, but these errors were encountered: