Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide interface to spawn a new wasm component #25

Open
pothos opened this issue Sep 27, 2023 · 1 comment
Open

Provide interface to spawn a new wasm component #25

pothos opened this issue Sep 27, 2023 · 1 comment

Comments

@pothos
Copy link

pothos commented Sep 27, 2023

I know this involves a lot of design work and problems to tackle. Yet, in the long run I think the need for spawning wasm components will arise. In my naive view the interface would expect the binary component code and allow for composition to, e.g., pass stdin stream data and read stdout stream data from the currently running component. Since this consumes new host memory, the spawning is allowed to fail due to runtime memory limits.

One could emulate this behavior by running a wasm interpreter (since bytecode generation would not help) but it bloats the overall binary size and the speed of the spawned component would be slow. Also, I think that this would be the last piece in a real "wasm OS" where the part that compositions components does not need to be native code and thus any wasm runtime can run it. Think about a simple wasm shell - one can do this in native code or JS for the browser but not in wasm as of now.

@lukewagner
Copy link
Member

I think you're right that we need a way to spawn a new component at runtime; there are plenty of great use cases for that (some already documented in the Component Model's UseCases.md here. When you dig into how efficient linkage and lifetime management (of these component instances) should work, I think the right place to add this functionality is in the Component Model directly, as a runtime-callable variant of the existing instantiate expression, returning an owned handle to the new instance. (Early in the process of proposing the Component Model, I had this slide showing the spectrum of options and their implications, and "runtime instantiate" corresponds to the second-to-leftmost column.) Unfortunately, I think this might take a bit more time (I think it's the next big feature to add after native async support, although perhaps some of the work is parallelizable with async).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants