Skip to content
This repository was archived by the owner on Nov 25, 2025. It is now read-only.
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 20 additions & 3 deletions wit-0.3.0-draft/run.wit
Original file line number Diff line number Diff line change
@@ -1,6 +1,23 @@
@since(version = 0.3.0)
interface run {
/// Run the program.
@since(version = 0.3.0)
run: func() -> result;
/// Run the program.
///
/// This function is only meant to be called once per Wasm instance. If it
/// is called more, it will immediately fail with `error.already-called`.
///
/// If a program wishes to exit with a specific exit status value, it should
/// use the `exit.exit-with-code` function to exit rather than returning
/// from `run`.
@since(version = 0.3.0)
run: func() -> result<_, error>;

/// An error code returned by `run`.
@since(version = 0.3.0)
enum error {
/// The program did not complete successfully.
error,

/// The `run` function has already been called in the callee's instance.
already-called

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

It seems that this error case would be returned only in scenarios where the caller is malfunctioning.

If the caller is the host runtime, then that means that the host has instantiated the component, called run on it once and then called it again using the same store - effectively, the guest would signal to the host that the host's implementation has a bug. Is there a way that the host can handle this error and recover in any way?

Similarly, and IMO, more rare usage of this, would be a component composition, where a component is calling run on another component. Similarly, since this is a logical error, is there any reasonable recovery mechanism the caller can use if it receives already-called?

Looking at it from another perspective, every guest toolchain would need to track this state and return this error if run is called more than once. Are we confident that every toolchain would actually do that and return this error? In other words, can callers reliably assert that if a run() has returned error::error that it is not "caller's fault"?

Overall, I am struggling to find a use case for this error case, could you perhaps provide some examples of how this could be used?

}
}