Summary
Explore running multiple runtimes together — e.g., a Python guest that can shell out to Bash, or two cooperating guests with different runtimes.
Background
A single-unikernel approach was POC'd (bundling both Python and Bash into one guest and using subprocess) with mixed results. Worth noting that Unikraft's single address space design not support fork/exec well.
Possible approach: multi-guest with shared state
Instead of one unikernel running both runtimes, run two separate guests (one Python, one Bash) and have them communicate through the host:
- Host mediates state sharing between guests (shared memory region, message passing via host functions, or a temp filesystem via
--mount)
- Guest A dispatches work to Guest B through a host-side orchestration layer
- hyperagent already does something like this for its audit feature — reference that design
Questions
- What's the right communication primitive? (host-mediated message queue, shared
--mount directory, new host functions?)
- How does the host orchestrate lifecycle? (spin up Guest B on demand vs. keep both running?)
- Latency budget — is a host round-trip per cross-runtime call acceptable?
Summary
Explore running multiple runtimes together — e.g., a Python guest that can shell out to Bash, or two cooperating guests with different runtimes.
Background
A single-unikernel approach was POC'd (bundling both Python and Bash into one guest and using
subprocess) with mixed results. Worth noting that Unikraft's single address space design not supportfork/execwell.Possible approach: multi-guest with shared state
Instead of one unikernel running both runtimes, run two separate guests (one Python, one Bash) and have them communicate through the host:
--mount)Questions
--mountdirectory, new host functions?)