PHP.wasm: Explore WASMFS/OPFS

[adamziel]

Exploring a switch to WASMFS and lean on the native OPFS support.

See emscripten-core/emscripten#15949

This is not viable today. Let's keep revisiting it every six months.

This work leans on JSPI. I don't see a way of adopting WASMFS with OPFS backend without maintaining two very different PHP.wasm releases until JSPI is widely supported.

Why OPFS?

If this worked AND it has decent support for locks (SQLite-wise), we could:

• Parallelize requests over, say, five workers writing to the same filesystem without overwriting each other's changes
• Run the same Playground site in multiple browser tabs
• Work with local files without having to click "Synchronize changes"
• Get rid of journaling

Why WASMFS?

If we only got WASMFS to work without the OPFS backend, we could:

• Remove custom C patches that make open(), write(), poll() etc. asynchronous. We would still need to patch anything that calls fork(), though.

Technical limitations

• Non-JSPI runtimes would still need to rely on the custom C patches and the JavaScript FS API. (Safari, Node.js <= 22, Bun, ...)
  • This is a dealbreaker. Maintaining two, very different Playground builds would be quite a burden. It will take a few years for the next Node LTS version to be released and there's no timeline on JSPI support in webkit. Let's keep this on hold, then.
• PROXYFS is not supported in WASMFS (yet?)
• Non-OPFS runtimes would still rely on memory backend (Safari in private mode, embeds in Firefox, likely enterprise browsers)

[adamziel]

Concurrent writes to the same OPFS filesystem from multiple browser tabs seem to be an uncharted territory. The browser would need similar synchronization mechanisms as the regular filesystem.

Notion encountered the same problem and ended up using a SharedWorker. This would technically enable us to run multiple Playground workers for the same site, but it would introduce a shared bottleneck in form of that SharedWorker. The entire premise of running, say, 5 concurrent PHP workers would be to parallelize the computations and handle concurrent requests independently using some form of round-robin across all the running workers.