Skip to content

[k2] introduce component structure and confdata multishot component skeleton - #1671

Open
apolyakov wants to merge 11 commits into
masterfrom
apolyakov/k2-confdata-component-init
Open

[k2] introduce component structure and confdata multishot component skeleton#1671
apolyakov wants to merge 11 commits into
masterfrom
apolyakov/k2-confdata-component-init

Conversation

@apolyakov

Copy link
Copy Markdown
Contributor

Restructure the K2 runtime to support multiple component images:

  • Move the kphp component's entry points and state to runtime-light/components/kphp/
  • Decouple common runtime code from the concrete component state: all state accessors (*::get / *::try_get / *::get_mutable) are resolved via link-time bindings in each component's bindings/bindings.cpp, keeping common code agnostic of where the state actually lives
  • Add components/confdata/: a standalone C++ component image (k2-confdata.so) mirroring the kphp component structure — own state, bindings, entry points, hand-written k2_describe(). The dummy instance accepts a stream, drains the request and closes it; a trivial warmup entry point is in place

Prepare runtime-light for multiple component entry points: the kphp
component's sources (runtime-light.cpp and state/) move to
components/kphp/, making room for sibling components (e.g. confdata).
Includes are updated accordingly; .gitignore's bare "kphp" pattern is
anchored to the repo root so it no longer hides the new directory.
Common runtime code no longer depends on the concrete kphp InstanceState:
state accessors (kphp::coro::instance_state::get, io_scheduler::get,
AllocatorState::get, ErrorHandlingState, RuntimeContext::get,
contextual_tags::try_get) are resolved via link-time bindings implemented
in components/kphp/bindings/bindings.cpp. CoroutineInstanceState is moved
into kphp::coro as instance_state, io_scheduler receives it via its
constructor, and async_backtrace reaches the stack root through the
binding instead of the concrete state layout.
Introduce components/confdata/: a standalone C++ component image that
mirrors the kphp component structure (state/, bindings/, entry points)
and links the common runtime-light machinery (coroutine scheduler,
script allocator, streams, logging) via the per-component bindings
introduced earlier. The dummy instance accepts a stream, drains the
request and closes it; k2_describe() is hand-written with the
"confdata" image name. The k2-confdata.so image is produced by cmake
with the same link recipe the compiler uses for k2 images, and
confdata headers are excluded from the merged runtime headers.
Every *::get / *::try_get / *::get_mutable definition (and
PhpScriptMutableGlobals::current) now lives in
components/kphp/bindings/bindings.cpp, so common runtime-light code no
longer includes components/kphp/state headers from its .cpp files and
stays fully agnostic of where the state actually lives. The 22 state
.cpp files that contained nothing but accessors are removed;
file-system-state.cpp keeps its constructor and php-script-globals.cpp
keeps its logic. Direct InstanceState accesses in http and job-worker
init code now go through PhpScriptMutableGlobals::current(). Another
component can adopt a runtime-light .cpp incrementally by adding the
corresponding binding to its own bindings.cpp.
@apolyakov apolyakov added this to the next milestone Aug 5, 2026
@apolyakov apolyakov self-assigned this Aug 5, 2026
@apolyakov apolyakov added runtime Feature related to runtime k2 Affects compiler or runtime in K2 mode labels Aug 5, 2026

@KPHP-CI KPHP-CI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

k2 Affects compiler or runtime in K2 mode runtime Feature related to runtime

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants