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

Allow start functions to call imports. #300

Merged
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
12 changes: 0 additions & 12 deletions design/mvp/Explainer.md
Original file line number Diff line number Diff line change
Expand Up @@ -1624,18 +1624,6 @@ three runtime invariants:
more-efficient non-reentrant runtime glue code (particularly in the middle
of the [Canonical ABI](CanonicalABI.md)). This implies that components by
default don't allow concurrency and multi-threaded access will trap.
3. Components enforce the current informal rule that `start` functions are
only for "internal" initialization by trapping if a component attempts to
call a component import during instantiation. In Core WebAssembly, this
invariant is not viable since cross-module calls are often necessary when
initializing shared linear memory (e.g., calling `libc`'s `malloc`).
However, at the granularity of components, this invariant appears viable and
would allow runtimes and toolchains considerable optimization flexibility
based on the resulting purity of instantiation. As one example, tools like
[`wizer`] could be used to *transparently* snapshot the post-instantiation
state of a component to reuse in future instantiations. As another example,
a component runtime could optimize the instantiation of a component DAG by
transparently instantiating non-root components lazily and/or in parallel.


## JavaScript Embedding
Expand Down
Loading