Stream: rfc-notifications

Topic: rfcs / issue #11 RFC: Redesign Wasmtime's API

view this post on Zulip RFC notifications bot (May 12 2021 at 15:46):

alexcrichton commented on issue #11:

I've updated with a tweak to the APIs in languages like Python, Go, and .NET. Originally I intended that "pass the store around" wouldn't be as common there, but the behavior of the GC in Go and converting a wasmtime_val_t to a wasmtime_func_t has tipped my opinion in favor of "pass the store everyhwere" like what happens in C & Rust.

view this post on Zulip RFC notifications bot (May 24 2021 at 18:11):

alexcrichton commented on issue #11:

Motion to finalize with a disposition to merge

We've reached out to various Wasmtime embedders, and have received very positive feedback on the changes proposed here. Additionally, we have full implementations of the proposal for Wasmtime's Rust and C-APIs, wasmtime-py, and wasmtime-go.

We also analyzed the impact on various existing embeddings, and found it to be very reasonable in all cases.

As such, we proposing finalizing this RFC with a disposition to merge it.

Stakeholders sign-off

Given the broad impact of these changes, we decided to also tag a broad list of contributors and Wasmtime embedders for feedback.

Arm

DFINITY

Embark Studios

Fastly

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (May 24 2021 at 18:12):

acfoltzer commented on issue #11:

[ ] @acfoltzer

view this post on Zulip RFC notifications bot (May 24 2021 at 18:12):

acfoltzer edited a comment on issue #11:

view this post on Zulip RFC notifications bot (May 24 2021 at 18:13):

pchickey edited a comment on issue #11:

Motion to finalize with a disposition to merge

We've reached out to various Wasmtime embedders, and have received very positive feedback on the changes proposed here. Additionally, we have full implementations of the proposal for Wasmtime's Rust and C-APIs, wasmtime-py, and wasmtime-go.

We also analyzed the impact on various existing embeddings, and found it to be very reasonable in all cases.

As such, we proposing finalizing this RFC with a disposition to merge it.

Stakeholders sign-off

Given the broad impact of these changes, we decided to also tag a broad list of contributors and Wasmtime embedders for feedback.

Arm

DFINITY

Embark Studios

Fastly

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (May 24 2021 at 18:13):

peterhuene edited a comment on issue #11:

Motion to finalize with a disposition to merge

We've reached out to various Wasmtime embedders, and have received very positive feedback on the changes proposed here. Additionally, we have full implementations of the proposal for Wasmtime's Rust and C-APIs, wasmtime-py, and wasmtime-go.

We also analyzed the impact on various existing embeddings, and found it to be very reasonable in all cases.

As such, we proposing finalizing this RFC with a disposition to merge it.

Stakeholders sign-off

Given the broad impact of these changes, we decided to also tag a broad list of contributors and Wasmtime embedders for feedback.

Arm

DFINITY

Embark Studios

Fastly

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (May 24 2021 at 18:14):

fitzgen edited a comment on issue #11:

Motion to finalize with a disposition to merge

We've reached out to various Wasmtime embedders, and have received very positive feedback on the changes proposed here. Additionally, we have full implementations of the proposal for Wasmtime's Rust and C-APIs, wasmtime-py, and wasmtime-go.

We also analyzed the impact on various existing embeddings, and found it to be very reasonable in all cases.

As such, we proposing finalizing this RFC with a disposition to merge it.

Stakeholders sign-off

Given the broad impact of these changes, we decided to also tag a broad list of contributors and Wasmtime embedders for feedback.

Arm

DFINITY

Embark Studios

Fastly

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (May 24 2021 at 18:14):

fitzgen edited a comment on issue #11:

Motion to finalize with a disposition to merge

We've reached out to various Wasmtime embedders, and have received very positive feedback on the changes proposed here. Additionally, we have full implementations of the proposal for Wasmtime's Rust and C-APIs, wasmtime-py, and wasmtime-go.

We also analyzed the impact on various existing embeddings, and found it to be very reasonable in all cases.

As such, we proposing finalizing this RFC with a disposition to merge it.

Stakeholders sign-off

Given the broad impact of these changes, we decided to also tag a broad list of contributors and Wasmtime embedders for feedback.

Arm

DFINITY

Embark Studios

Fastly

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (May 24 2021 at 18:26):

cfallin edited a comment on issue #11:

Motion to finalize with a disposition to merge

We've reached out to various Wasmtime embedders, and have received very positive feedback on the changes proposed here. Additionally, we have full implementations of the proposal for Wasmtime's Rust and C-APIs, wasmtime-py, and wasmtime-go.

We also analyzed the impact on various existing embeddings, and found it to be very reasonable in all cases.

As such, we proposing finalizing this RFC with a disposition to merge it.

Stakeholders sign-off

Given the broad impact of these changes, we decided to also tag a broad list of contributors and Wasmtime embedders for feedback.

Arm

DFINITY

Embark Studios

Fastly

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (May 24 2021 at 18:37):

akirilov-arm edited a comment on issue #11:

Motion to finalize with a disposition to merge

We've reached out to various Wasmtime embedders, and have received very positive feedback on the changes proposed here. Additionally, we have full implementations of the proposal for Wasmtime's Rust and C-APIs, wasmtime-py, and wasmtime-go.

We also analyzed the impact on various existing embeddings, and found it to be very reasonable in all cases.

As such, we proposing finalizing this RFC with a disposition to merge it.

Stakeholders sign-off

Given the broad impact of these changes, we decided to also tag a broad list of contributors and Wasmtime embedders for feedback.

Arm

DFINITY

Embark Studios

Fastly

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (May 24 2021 at 18:38):

alexcrichton edited a comment on issue #11:

Motion to finalize with a disposition to merge

We've reached out to various Wasmtime embedders, and have received very positive feedback on the changes proposed here. Additionally, we have full implementations of the proposal for Wasmtime's Rust and C-APIs, wasmtime-py, and wasmtime-go.

We also analyzed the impact on various existing embeddings, and found it to be very reasonable in all cases.

As such, we proposing finalizing this RFC with a disposition to merge it.

Stakeholders sign-off

Given the broad impact of these changes, we decided to also tag a broad list of contributors and Wasmtime embedders for feedback.

Arm

DFINITY

Embark Studios

Fastly

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (May 24 2021 at 18:39):

alexcrichton commented on issue #11:

Entering Final Call Period

https://github.com/bytecodealliance/rfcs/blob/main/accepted/rfc-process.md#making-a-decision-merge-or-close

Once any stakeholder from a different group has signed off, the RFC will move into a 10 calendar day final comment period (FCP), long enough to ensure that other stakeholders have at least a full business week to respond.

The FCP will end on Thursday June 3.

view this post on Zulip RFC notifications bot (May 24 2021 at 19:05):

alexcrichton commented on issue #11:

I think it may be a little too early to say how we might support a proposal like that. The discussion on that issue is largely about thread id representation which is somewhat orthogonal to the embedding API. For the embedding API though the proposal is so vague at this point I'm not sure what our design constraints are. For example with a hypothetical thread.new instruction:

I'm sure there's other questions too, but without knowing much about the proposal it's hard to say what the embedding API might look like.

My rough mental model for the current wasm threads proposal (not to be confused with that issue for a native wasm thread) is that there'd be a Store-per-thread. Here T wouldn't need Send or Sync since the embedder would simply arrange the Store to be on its own thread somewhere else. Trying to fuse this with a native wasm threads proposal sort of looks like we'd need like a "store factory" where there's a built-in ability to create a Store on another thread. That namely does indeed need to create a T, and that could presumably be done with a custom trait/helper or even just T: Clone. This would indeed require T: Send. I don't think that T: Sync would make sense since we provide mutable access to the T which means that we can't share the T` across threads anyway.

Overall I don't think we're necessarily in a bad position to support a proposal like that, but it's tough to say given the current state. I do think that we're still better off than we are today where host state is littered across all sorts of host functions and such. The only state in a Store which is maybe not Send and Sync is the T itself. This means that all reasoning about thread-safety is entirely tied to T since everything else is threadsafe (e.g. host closures are all Fn() + Send + Sync).

Currently there's a bunch of pieces floating around where if you connect a few and squint hard it sort of looks like an implementation of a native threads proposal, but I think there needs to be more concrete design planning and such done first.

view this post on Zulip RFC notifications bot (May 24 2021 at 19:17):

alexcrichton edited a comment on issue #11:

Motion to finalize with a disposition to merge

We've reached out to various Wasmtime embedders, and have received very positive feedback on the changes proposed here. Additionally, we have full implementations of the proposal for Wasmtime's Rust and C-APIs, wasmtime-py, and wasmtime-go.

We also analyzed the impact on various existing embeddings, and found it to be very reasonable in all cases.

As such, we proposing finalizing this RFC with a disposition to merge it.

Stakeholders sign-off

Given the broad impact of these changes, we decided to also tag a broad list of contributors and Wasmtime embedders for feedback.

Arm

DFINITY

Embark Studios

Fastly

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (May 24 2021 at 19:30):

sunfishcode edited a comment on issue #11:

Motion to finalize with a disposition to merge

We've reached out to various Wasmtime embedders, and have received very positive feedback on the changes proposed here. Additionally, we have full implementations of the proposal for Wasmtime's Rust and C-APIs, wasmtime-py, and wasmtime-go.

We also analyzed the impact on various existing embeddings, and found it to be very reasonable in all cases.

As such, we proposing finalizing this RFC with a disposition to merge it.

Stakeholders sign-off

Given the broad impact of these changes, we decided to also tag a broad list of contributors and Wasmtime embedders for feedback.

Arm

DFINITY

Embark Studios

Fastly

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (May 24 2021 at 23:38):

alexcrichton edited a comment on issue #11:

Motion to finalize with a disposition to merge

We've reached out to various Wasmtime embedders, and have received very positive feedback on the changes proposed here. Additionally, we have full implementations of the proposal for Wasmtime's Rust and C-APIs, wasmtime-py, and wasmtime-go.

We also analyzed the impact on various existing embeddings, and found it to be very reasonable in all cases.

As such, we proposing finalizing this RFC with a disposition to merge it.

Stakeholders sign-off

Given the broad impact of these changes, we decided to also tag a broad list of contributors and Wasmtime embedders for feedback.

Arm

DFINITY

Embark Studios

Fastly

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (May 25 2021 at 16:29):

alexcrichton edited a comment on issue #11:

Motion to finalize with a disposition to merge

We've reached out to various Wasmtime embedders, and have received very positive feedback on the changes proposed here. Additionally, we have full implementations of the proposal for Wasmtime's Rust and C-APIs, wasmtime-py, and wasmtime-go.

We also analyzed the impact on various existing embeddings, and found it to be very reasonable in all cases.

As such, we proposing finalizing this RFC with a disposition to merge it.

Stakeholders sign-off

Given the broad impact of these changes, we decided to also tag a broad list of contributors and Wasmtime embedders for feedback.

Arm

DFINITY

Embark Studios

Fastly

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (May 25 2021 at 16:29):

alexcrichton edited a comment on issue #11:

Motion to finalize with a disposition to merge

We've reached out to various Wasmtime embedders, and have received very positive feedback on the changes proposed here. Additionally, we have full implementations of the proposal for Wasmtime's Rust and C-APIs, wasmtime-py, and wasmtime-go.

We also analyzed the impact on various existing embeddings, and found it to be very reasonable in all cases.

As such, we proposing finalizing this RFC with a disposition to merge it.

Stakeholders sign-off

Given the broad impact of these changes, we decided to also tag a broad list of contributors and Wasmtime embedders for feedback.

Arm

DFINITY

Embark Studios

Fastly

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (May 25 2021 at 16:29):

alexcrichton edited a comment on issue #11:

Motion to finalize with a disposition to merge

We've reached out to various Wasmtime embedders, and have received very positive feedback on the changes proposed here. Additionally, we have full implementations of the proposal for Wasmtime's Rust and C-APIs, wasmtime-py, and wasmtime-go.

We also analyzed the impact on various existing embeddings, and found it to be very reasonable in all cases.

As such, we proposing finalizing this RFC with a disposition to merge it.

Stakeholders sign-off

Given the broad impact of these changes, we decided to also tag a broad list of contributors and Wasmtime embedders for feedback.

Arm

DFINITY

Embark Studios

Fastly

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (May 25 2021 at 16:41):

mingqiusun edited a comment on issue #11:

Motion to finalize with a disposition to merge

We've reached out to various Wasmtime embedders, and have received very positive feedback on the changes proposed here. Additionally, we have full implementations of the proposal for Wasmtime's Rust and C-APIs, wasmtime-py, and wasmtime-go.

We also analyzed the impact on various existing embeddings, and found it to be very reasonable in all cases.

As such, we proposing finalizing this RFC with a disposition to merge it.

Stakeholders sign-off

Given the broad impact of these changes, we decided to also tag a broad list of contributors and Wasmtime embedders for feedback.

Arm

DFINITY

Embark Studios

Fastly

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (May 25 2021 at 20:43):

alexcrichton edited a comment on issue #11:

I think it may be a little too early to say how we might support a proposal like that. The discussion on that issue is largely about thread id representation which is somewhat orthogonal to the embedding API. For the embedding API though the proposal is so vague at this point I'm not sure what our design constraints are. For example with a hypothetical thread.new instruction:

I'm sure there's other questions too, but without knowing much about the proposal it's hard to say what the embedding API might look like.

My rough mental model for the current wasm threads proposal (not to be confused with that issue for a native wasm thread) is that there'd be a Store-per-thread. Here T wouldn't need Send or Sync since the embedder would simply arrange the Store to be on its own thread somewhere else. Trying to fuse this with a native wasm threads proposal sort of looks like we'd need like a "store factory" where there's a built-in ability to create a Store on another thread. That namely does indeed need to create a T, and that could presumably be done with a custom trait/helper or even just T: Clone. This would indeed require T: Send. I don't think that T: Sync would make sense since we provide mutable access to the T which means that we can't share the T across threads anyway.

Overall I don't think we're necessarily in a bad position to support a proposal like that, but it's tough to say given the current state. I do think that we're still better off than we are today where host state is littered across all sorts of host functions and such. The only state in a Store which is maybe not Send and Sync is the T itself. This means that all reasoning about thread-safety is entirely tied to T since everything else is threadsafe (e.g. host closures are all Fn() + Send + Sync).

Currently there's a bunch of pieces floating around where if you connect a few and squint hard it sort of looks like an implementation of a native threads proposal, but I think there needs to be more concrete design planning and such done first.

view this post on Zulip RFC notifications bot (Jun 02 2021 at 16:35):

bnjbvr edited a comment on issue #11:

Motion to finalize with a disposition to merge

We've reached out to various Wasmtime embedders, and have received very positive feedback on the changes proposed here. Additionally, we have full implementations of the proposal for Wasmtime's Rust and C-APIs, wasmtime-py, and wasmtime-go.

We also analyzed the impact on various existing embeddings, and found it to be very reasonable in all cases.

As such, we proposing finalizing this RFC with a disposition to merge it.

Stakeholders sign-off

Given the broad impact of these changes, we decided to also tag a broad list of contributors and Wasmtime embedders for feedback.

Arm

DFINITY

Embark Studios

Fastly

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (Jun 03 2021 at 08:16):

repi commented on issue #11:

Good stuff! :+1:

view this post on Zulip RFC notifications bot (Jun 03 2021 at 08:18):

bnjbvr edited a comment on issue #11:

Motion to finalize with a disposition to merge

We've reached out to various Wasmtime embedders, and have received very positive feedback on the changes proposed here. Additionally, we have full implementations of the proposal for Wasmtime's Rust and C-APIs, wasmtime-py, and wasmtime-go.

We also analyzed the impact on various existing embeddings, and found it to be very reasonable in all cases.

As such, we proposing finalizing this RFC with a disposition to merge it.

Stakeholders sign-off

Given the broad impact of these changes, we decided to also tag a broad list of contributors and Wasmtime embedders for feedback.

Arm

DFINITY

Embark Studios

Fastly

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (Jun 03 2021 at 14:09):

alexcrichton commented on issue #11:

Ok the FCP period has now finished and no objections have been raised. Time to merge then!

Last updated: Dec 23 2024 at 12:05 UTC