peterhuene commented on Issue #9:
Motion to finalize with a disposition to merge
I'm proposing that we merge this RFC.
Feedback has been addressed from the draft RFC and an implementation in Wasmtime is ready for review.
Stakeholders sign-off
Tagging all employees of BA-affiliated companies who have committed to the Wasmtime repo in the last three months plus anyone who has given feedback on this PR as a stakeholder.
Fastly
- [ ] @alexcrichton
- [ ] @pchickey
- [ ] @fitzgen
- [ ] @sunfishcode
- [ ] @cfallin
- [ ] @iximeow
IBM
- [ ] @uweigand
Intel
- [ ] @abrown
Mozilla
- [ ] @julian-seward1
- [ ] @yurydelendik
sunfishcode edited a comment on Issue #9:
Motion to finalize with a disposition to merge
I'm proposing that we merge this RFC.
Feedback has been addressed from the draft RFC and an implementation in Wasmtime is ready for review.
Stakeholders sign-off
Tagging all employees of BA-affiliated companies who have committed to the Wasmtime repo in the last three months plus anyone who has given feedback on this PR as a stakeholder.
Fastly
- [ ] @alexcrichton
- [ ] @pchickey
- [ ] @fitzgen
- [x] @sunfishcode
- [ ] @cfallin
- [ ] @iximeow
IBM
- [ ] @uweigand
Intel
- [ ] @abrown
Mozilla
- [ ] @julian-seward1
- [ ] @yurydelendik
alexcrichton edited a comment on Issue #9:
Motion to finalize with a disposition to merge
I'm proposing that we merge this RFC.
Feedback has been addressed from the draft RFC and an implementation in Wasmtime is ready for review.
Stakeholders sign-off
Tagging all employees of BA-affiliated companies who have committed to the Wasmtime repo in the last three months plus anyone who has given feedback on this PR as a stakeholder.
Fastly
- [x] @alexcrichton
- [ ] @pchickey
- [ ] @fitzgen
- [x] @sunfishcode
- [ ] @cfallin
- [ ] @iximeow
IBM
- [ ] @uweigand
Intel
- [ ] @abrown
Mozilla
- [ ] @julian-seward1
- [ ] @yurydelendik
peterhuene edited a comment on Issue #9:
Motion to finalize with a disposition to merge
I'm proposing that we merge this RFC.
Feedback has been addressed from the draft RFC and an implementation in Wasmtime is ready for review.
Stakeholders sign-off
Tagging all employees of BA-affiliated companies who have committed to the Wasmtime repo in the last three months plus anyone who has given feedback on this PR as a stakeholder.
Fastly
- [x] @alexcrichton
- [ ] @pchickey
- [ ] @fitzgen
- [x] @sunfishcode
- [x] @cfallin
- [ ] @iximeow
IBM
- [ ] @uweigand
Intel
- [ ] @abrown
Mozilla
- [ ] @julian-seward1
- [ ] @yurydelendik
peterhuene edited a comment on Issue #9:
Motion to finalize with a disposition to merge
I'm proposing that we merge this RFC.
Feedback has been addressed from the draft RFC and an implementation in Wasmtime is ready for review.
Stakeholders sign-off
Tagging all employees of BA-affiliated companies who have committed to the Wasmtime repo in the last three months plus anyone who has given feedback on this PR as a stakeholder.
Fastly
- [x] @alexcrichton
- [ ] @pchickey
- [ ] @fitzgen
- [x] @sunfishcode
- [x] @cfallin
- [ ] @iximeow
IBM
- [ ] @uweigand
Intel
- [x] @abrown
Mozilla
- [ ] @julian-seward1
- [ ] @yurydelendik
fitzgen edited a comment on Issue #9:
Motion to finalize with a disposition to merge
I'm proposing that we merge this RFC.
Feedback has been addressed from the draft RFC and an implementation in Wasmtime is ready for review.
Stakeholders sign-off
Tagging all employees of BA-affiliated companies who have committed to the Wasmtime repo in the last three months plus anyone who has given feedback on this PR as a stakeholder.
Fastly
- [x] @alexcrichton
- [ ] @pchickey
- [x] @fitzgen
- [x] @sunfishcode
- [x] @cfallin
- [ ] @iximeow
IBM
- [ ] @uweigand
Intel
- [x] @abrown
Mozilla
- [ ] @julian-seward1
- [ ] @yurydelendik
benaubin commented on Issue #9:
Preface: I'm new to the wasmtime codebase (but would love to start contributing), and I might be completely offbase with this.
Would it be possible to make this the "naïve import type bound" to make
Store
Send
that @alexcrichton was discussing in https://github.com/bytecodealliance/wasmtime/issues/793?
benaubin edited a comment on Issue #9:
Preface: I'm new to the wasmtime codebase (but would love to get up to speed and start contributing in the future), and I might be completely offbase with this.
Would it be possible to make this the "naïve import type bound" to make
Store
Send
that @alexcrichton was discussing in https://github.com/bytecodealliance/wasmtime/issues/793?
benaubin edited a comment on Issue #9:
Preface: I'm new to the wasmtime codebase (but would love to get up to speed and start contributing in the future), and I might be completely offbase with this.
Would it be possible to make this the "import object bound" that makes
Store impl Send
, as @alexcrichton was discussing in https://github.com/bytecodealliance/wasmtime/issues/793?
benaubin edited a comment on Issue #9:
Preface: I'm new to the wasmtime codebase (but would love to get up to speed and start contributing in the future), and I might be completely offbase with this.
Would it be possible to somehow turn this into the "import object bound" that makes
Store impl Send
, as @alexcrichton was discussing in https://github.com/bytecodealliance/wasmtime/issues/793?
peterhuene commented on Issue #9:
The problem this RFC tries to address isn't really related to
Instance
(orStore
) not beingSend
as even ifInstance
wereSend
, short-lived instances (implying a short-livedStore
as instances are not deallocated until theStore
owning them drops) would need to have host functions redefined when a newStore
is created.This RFC calls for defining host functions in a way that is not tied to a
Store
and therefore can be used from anyStore
without having to redefine them.As
Module
isSend+Sync
, this change would allow a "main" thread to define all of the host functions, load the module, and then when a service request comes in send the module to another thread that creates a newStore
and instantiates the module without having to define the host functions while servicing the request itself.Does that explanation make sense?
peterhuene edited a comment on Issue #9:
The problem this RFC tries to address isn't really related to
Instance
(orStore
) being!Send
as even ifInstance
wereSend
, short-lived instances (implying a short-livedStore
as instances are not deallocated until theStore
owning them drops) would need to have host functions redefined when a newStore
is created.This RFC calls for defining host functions in a way that is not tied to a
Store
and therefore can be used from anyStore
without having to redefine them.As
Module
isSend+Sync
, this change would allow a "main" thread to define all of the host functions, load the module, and then when a service request comes in send the module to another thread that creates a newStore
and instantiates the module without having to define the host functions while servicing the request itself.Does that explanation make sense?
benaubin commented on Issue #9:
That makes a lot of sense, thank you! I see how this solves much of the same use case.
peterhuene commented on Issue #9:
Entering Final Call Period
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 Mon Mar 9.
peterhuene edited a comment on Issue #9:
Entering Final Call Period
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 Tue Mar 9.
peterhuene commented on Issue #9:
The FCP has elapsed without any objections being raised; as a result I'm going to merge this. Thanks everyone!
Last updated: Nov 22 2024 at 17:03 UTC