Prototype: Spawning PHP sub-processes in Web Workers

[adamziel]

Related to #1026 and #1027

Adds support for spawning PHP subprocesses via <?php proc_open(['php', 'activate_theme.php']);. The spawned subprocess affects the filesystem used by the parent process.

Implementation details

This PR adds a spawnHandler that does the following:

1. Creates another instance of WebPHP (child)
2. Populates child's FS with parent's files
3. Runs requested PHP script the child
4. Syncs the child FS changes back to the parent

A shared filesystem didn't pan out. Synchronizing is the second best option.

This code snippet illustrates the idea – note the actual implementation is more nuanced:

php.setSpawnHandler(
	createSpawnHandler(async function (args, processApi) {
		const childPHP = new WebPHP();
		syncFS(php, childPHP);
		const { exitCode, stdout, stderr } = await childPHP.run({
			scriptPath: args[1]
		});
		syncFS(childPHP, php);
		processApi.stdout(stdout);
		processApi.stderr(stderr);
		processApi.exit(exitCode);
	})
);

Future work

• Stream stdout and stderr from childPHP to processApi instead of buffering the output and passing everything at once

Example of how it works

/wordpress/spawn.php

<?php
echo "<plaintext>";
echo "Spawning /wordpress/child.php\n";
$handle = proc_open('php /wordpress/child.php', [
	0 => ['pipe', 'r'],
	1 => ['pipe', 'w'],
	2 => ['pipe', 'w'],
], $pipes);

echo "stdout: " . stream_get_contents($pipes[1]) . "\n";
echo "stderr: " . stream_get_contents($pipes[2]) . "\n";
echo "Finished\n";
echo "Contents of the created file: " . file_get_contents("/wordpress/new.txt") . "\n";

/wordpress/child.php

<?php
echo "<plaintext>";
echo "Spawned, running";
error_log("Here's a message logged to stderr! " . rand());
file_put_contents("/wordpress/new.txt", "Hello, world!" . rand() . "\n");

Testing instructions

• Go to http://localhost:5400/website-server/?url=/spawn.php and confirm the output looks as on the screenshot above

Unit tests, E2E tests, and more testing instructions coming soon.

cc @dmsnell @bgrgicak

[dmsnell]

while normal environments share the FS across running PHP instances, I wonder if there would be a special reason to lock the FS during Playground bootup, in case something depends on having certain plugins installed or wants to read config values. I'm thinking about the case where a worker and main thread are both initializing at the same time. did you work through these cases?

[adamziel]

while normal environments share the FS across running PHP instances, I wonder if there would be a special reason to lock the FS during Playground bootup, in case something depends on having certain plugins installed or wants to read config values. I'm thinking about the case where a worker and main thread are both initializing at the same time. did you work through these cases?

Both PHP instances run in the same worker so there is no concurrency involved. Everything is happening sequentially. Assuming reliable two-way Filesystem sync, both PHP instances would have access to the same plugins and config values.

[adamziel]

Perhaps we don't need to sync filesystem changes after all. Emscripten provides PROXYFS that could potentially enable mounting one of the filesystems in the other, effectively making both PHP instances work with the same files.

[adamziel]

Here's an alternative idea for FS syncing:

for ( const path of [DOCROOT, "/tmp"] ) {
	childPHP[__private__dont__use].FS.mount(childPHP[__private__dont__use].PROXYFS, {
		root: path,
		fs: php[__private__dont__use].FS
	}, path);
}

[adamziel]

Superseded by #1069