diff options
| author | nsfisis <nsfisis@gmail.com> | 2026-08-07 20:51:59 +0900 |
|---|---|---|
| committer | nsfisis <nsfisis@gmail.com> | 2026-08-07 20:51:59 +0900 |
| commit | ae365645730b95d5b01b0df7382b91668d5fa24e (patch) | |
| tree | 962e3abb51132097ff11a79d453e058945ae699c /docs/dev | |
| parent | f749a47804cd296a3059cd3f8079c62dbaa5fdc0 (diff) | |
| download | php-shirabe-ae365645730b95d5b01b0df7382b91668d5fa24e.tar.gz php-shirabe-ae365645730b95d5b01b0df7382b91668d5fa24e.tar.zst php-shirabe-ae365645730b95d5b01b0df7382b91668d5fa24e.zip | |
refactor(platform-repository): fetch the PHP runtime in one RPC call
The RuntimeInterface seam asked the worker one question at a time: a round
trip per loaded extension, per ReflectionExtension::info() output and per
constant, so a single `show --platform` cost 70 to 100 of them. A `platform`
dispatch entry now answers all of it as one PHP array, which shirabe-php-rpc
decodes into a OnceLock-cached PlatformInfo, the way the diagnose command
already works.
Composer\Platform\Runtime therefore has no Rust counterpart any more. Its
work belongs to the running interpreter, and invoke()/construct() could only
be ported as a whitelist that panicked on anything unlisted; it is ported as
PHP into the worker instead, and PlatformRepository reads the answers off
PlatformInfo. Accessors panic on a name the payload does not carry, so the
worker and its consumers cannot drift apart unnoticed.
The tests describe the runtime as payload data where they used to mock the
seam, with the datasets unchanged. The one loss is the call-count assertion
of test_inet_pton_regression: the payload reports the result of
`@inet_pton('::')` rather than answering a call.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Diffstat (limited to 'docs/dev')
| -rw-r--r-- | docs/dev/php-rpc.md | 18 |
1 files changed, 12 insertions, 6 deletions
diff --git a/docs/dev/php-rpc.md b/docs/dev/php-rpc.md index 392b318e..c833bbea 100644 --- a/docs/dev/php-rpc.md +++ b/docs/dev/php-rpc.md @@ -5,9 +5,7 @@ and its plugin/script machinery executes real PHP code. To mimic this behavior n runtime. The `shirabe-php-rpc` crate spawns the system PHP as a child process and talks to it over a Unix -domain socket. There is exactly one child process per Shirabe process, shared by every caller; -it hosts both the simple runtime queries (`get_php_version`, `has_constant`, ...) and the plugin -protocol. +domain socket. There is exactly one child process per Shirabe process, shared by every caller. ## Locating PHP @@ -129,9 +127,17 @@ same dispatch while waiting for its own `Return`. ## Worker dispatch table -`CallFunction` first consults the worker's dispatch table (composite queries like `diagnose`, -Shirabe-internal helpers prefixed `__shirabe_`), then falls back to calling the named PHP -function; an unknown name is an explicit error. Notable internal helpers: +`CallFunction` first consults the worker's dispatch table (composite queries like `diagnose` and +`platform`, Shirabe-internal helpers prefixed `__shirabe_`), then falls back to calling the named +PHP function; an unknown name is an explicit error. + +A composite query answers everything one consumer needs about the runtime in a single round trip, +because asking one constant and one extension at a time costs a round trip each. The Rust side +decodes the answer into a struct cached in a `OnceLock` (`Diagnostics` for `diagnose`, +`PlatformInfo` for `platform`) whose accessors panic on a name the worker does not report, so a +consumer and the worker cannot drift apart unnoticed. + +Notable internal helpers: - `__shirabe_eval` — runs a Rust-generated PHP snippet and returns its `return` value (used by the `scripts` Command-class execution path and the `_composer_tmp` class-rename path of |
