PHP WASM: Compile PHP to WASI

[eliot-akira]

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.

Let's look into collaborating with https://github.com/vmware-labs/webassembly-language-runtimes (see php-8.1.11) once WASI supports longjmp.

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 setjmp support. It was closed with the following note:

The current plan is to wait for the exception-handling proposal to be standardized and implemented in wasm engines, and then to implement setjmp and longjmp using that feature. Exception-handling is currently in phase 3.

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 setjmp and longjmp with Asyncify. I learned about it from these articles:

• Ruby 3.2's WASI Integration: A Closer Look
• An Update on WebAssembly/WASI Support in Ruby

Then someone re-purposed that setjmp polyfill to integrate with PHP. Here's the as-yet-unmerged pull request:

• Initial support for setjmp/longjmp for PHP v7.4.32 vmware-labs/webassembly-language-runtimes#28

In parallel, another person from VMware started on an ambitious effort in the PHP repo itself.

• [RFC] Add support for building to the wasm32-wasi target php/php-src#10457

---

Hopefully this issue can serve as reference when there's progress in any of the above.

[adamziel]

What a great issue @eliot-akira, thank you so much for putting all this information together!

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.

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]

Related:

• https://github.com/bjorn3/browser_wasi_shim
• https://github.com/ktock/container2wasm

[adamziel]

The Python WASI demo shipped with container2wasm even handled os.fork():

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_test

Now, 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.

[adamziel]

Container2Wasm demos are impressive but also too slow for any real-world use:

• The python demo transfers around 60MB of data (vs ~2.5MB for Playground's PHP)
• It took ~25 seconds to boot after it was downloaded (vs ~1s for Playground)
• It works in Chrome and Firefox, but not in Safari (Unhandled Promise Rejection: RangeError: Maximum call stack size exceeded.)

browser_wasi_shim is promising and its filesystem implementation looks much cleaner than the Emscripten's one, but it has important limitations:

• No async IO, that's a deal breaker. I think that means no Asyncify-like stack switching, either? Maybe when the JSPI proposal gets shipped in all major browsers?
• No fork support, so it wouldn't bring native support for proc_open etc, we'd still need patches.

On the upside, there were some explorations to support the WebAssembly Component Model.

Either way, there's nothing actionable here today.

[adamziel]

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