PHP Process Manager

[adamziel]

Adds a PHP Process manager, a class that can spawn maintain a number of PHP instances at the same time.

The idea is to have:

• A single "primary" PHP instance that's never killed – it contains the reference filesystem used by all other PHP instances.
• A pool of disposable PHP instances that are spawned to handle a single request and reaped immediately after.

Spawning new PHP instances is reasonably fast and can happen on demand, there's no need to keep a pool of "warm" instances that occupies the memory all the time.

Example usage:

const mgr = new PHPProcessManager({ phpFactory: async () => NodePHP.load(RecommendedPHPVersion), maxPhpInstances: 4, }); const instance = await mgr.getInstance(); await instance.php.run({ code }); instance.reap();

Related to #1287

Remaining work

• Add a "context" parameter to getInstance() to enable setting the correct SAPI Name, e.g. CLI or FPM depending on the purpose the PHP instance is created for. This would solve issues like PHP content type headers ignored? #1223. Alternatively, the consuming program could call setSapiName() on the PHP instance returned by getInstance() – but that assumes the factory did not initialize the web runtime.

Testing instructions

Confirm the unit tests pass. This PR only adds new code, it does not plug in the PHPProcessManager class into any request dispatching code yet.

[adamziel]

cc @dmsnell @brandonpayton @bgrgicak for reviews – this is an important component and I'd love to discuss it before moving further.

[bgrgicak]

this is an important component and I'd love to discuss it before moving further.

The approach makes sense to me. Do you have any specific concerns?

[adamziel]

The approach makes sense to me. Do you have any specific concerns?

Nothing specific, I just wanted to make sure I get some really smart folks to take a look :-)

[brandonpayton]

@adamziel, here are my thoughts and questions so far. I may keep reading and thinking about this for a bit but want to get some feedback out there.

In addition to the inline feedback, some other questions are:

• Does there need to be a primary PHP instance?
• What happens if a consumer disposes of the primary PHP instance? Does it matter?
• Would it make sense to track parent/child relationships? Maybe that is something best left to the consumer of the PHP Process Manager.

[adamziel]

All good notes @brandonpayton, thank you!

Does there need to be a primary PHP instance?

#1301 (comment)

What happens if a consumer disposes of the primary PHP instance? Does it matter?

They don't get access to a reap() function that would actually call php.exit(). If they do call php.exit() manually, their program will break. It's a footgun for sure, but I'm okay with responding to that "well just don't call exit() then" :-) If it bites us at one point, we can add a check like if(primary.hasExited()) { throw new Error("The primary PHP instance have exited and this PHPProcessManager can no longer be used. Make sure to avoid calling php.exit(), that's managed for you. "); }

Would it make sense to track parent/child relationships? Maybe that is something best left to the consumer of the PHP Process Manager.

I was thinking about that and here's what I realized:

• It would be handy to kill the entire child process group, as in Erlang's supervisor trees.
• We can track that when PHP spawns another one directly, as in proc_open(), but we cannot easily track that when PHP issues a loopback request via HTTP and that request spawns another process – in this case it would technically be a child of the request handler.
• At the same time, the request handler isn't a WASM module in the same sense as PHP so now we'd have to introduce more OS-like primitives with a generic process interface, a process table or a supervisor tree, potentially implement file descriptors outside of WASM context etc. I'd rather avoid that complexity while we can. Eventually perhaps we could just build a real process manager to WASM, add custom handlers, and get a lot of that for free?

[adamziel]

The unit test failure is an intermittent timeout. I've addressed the feedback and I'll go ahead and merge this one. Thank you so much for the discussion!