RFC: shared host functions.

[peterhuene]

Rendered RFC

This RFC proposes to extend the Wasmtime API to allow users to define host
functions in a Config that can be shared between multiple engines and
therefore stores.

Today, Func is used to define host functions, but it is tied to a Store.
If users desire short-lived stores to ensure short-lived instances, host
functions need to be redefined upon every module instantiation.

By defining host functions with a Config, instances can be created
without having to redefine the host functions; this will make for faster module
instantiations in scenarios where a module is repeatedly instantiated.

[sunfishcode]

This looks good to me!

On the WasiCtx in particular, the way I now see this is that all of the things we currently store in WasiCtx will eventually be moved out to be stored in other places. With the switch to handles and resources, we'll no longer need things like the entries table inside WasiCtx; we'll just have handles and resources.

[peterhuene]

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

[benaubin]

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 bytecodealliance/wasmtime#793?

[peterhuene]

The problem this RFC tries to address isn't really related to Instance (or Store) being !Send as even if Instance were Send, short-lived instances (implying a short-lived Store as instances are not deallocated until the Store owning them drops) would need to have host functions redefined when a new Store 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 any Store without having to redefine them.

As Module is Send+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 new Store and instantiates the module without having to define the host functions while servicing the request itself.

Does that explanation make sense?

[benaubin]

That makes a lot of sense, thank you! I see how this solves much of the same use case.

[peterhuene]

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 Tue Mar 9.

[peterhuene]

The FCP has elapsed without any objections being raised; as a result I'm going to merge this. Thanks everyone!