Stream: git-wasmtime

Topic: wasmtime / issue #7714 Support `Resource<T> -> ResourceAn...

view this post on Zulip Wasmtime GitHub notifications bot (Dec 20 2023 at 18:07):

rvolosatovs opened issue #7714:

Feature

With #7688 implemented it is now possible to take Resource<T> to ResourceAny, however it does not work for resources provided by wasmtime_wasi crate, since the ResourceImportIndex is not exposed to the developer of those resources.
This is particularly important for dynamically-defined functions defined via Linker::func_new, which operates on wasmtime::Val directly. For example, it is currently not possible to return a wasi:io/poll/pollable resource from such a function without defining a custom wasi:io/poll/pollable implementation in the linker to acquire the import index to pass to try_into_resource_any in order to convert it to ResourceAny

Benefit

This allows dymanically-typed function definitions to operate on resources provided by WASI, i.e. it removes the need for developers using dynamically-typed functions utilizing WASI resources from reimplementing (parts of) WASI

Implementation

Since lookups by string import paths were considered too slow for #7688, it appears that the only alternative would be adapting wit-bindgen (e.g https://github.com/bytecodealliance/wasmtime/blob/61e1cdff5a90461ab8de471e100de5b824e079d1/crates/wit-bindgen/src/lib.rs#L810) to capture the indexes returned by LinkerInstance::resource calls in a table of some sorts returned by add_to_linker, if we still want to avoid the string lookups, that could be a nested struct type, where an index lookup could look something like this:

let idx = resource_definitions.wasi.io.poll.pollable

Alternatives

Allow string lookups for the RuntimeImportIndex as an alternative to the ResourceImportIndex computed at LinkerInstance::resource

view this post on Zulip Wasmtime GitHub notifications bot (Dec 20 2023 at 18:07):

rvolosatovs edited issue #7714:

Feature

With #7688 implemented it is now possible to take Resource<T> to ResourceAny, however the conversion does not work for resources provided by wasmtime_wasi crate, since the ResourceImportIndex is not exposed to the developer of those resources.

This is particularly important for dynamically-defined functions defined via Linker::func_new, which operates on wasmtime::Val directly. For example, it is currently not possible to return a wasi:io/poll/pollable resource from such a function without defining a custom wasi:io/poll/pollable implementation in the linker to acquire the import index to pass to try_into_resource_any in order to convert it to ResourceAny

Benefit

This allows dymanically-typed function definitions to operate on resources provided by WASI, i.e. it removes the need for developers using dynamically-typed functions utilizing WASI resources from reimplementing (parts of) WASI

Implementation

Since lookups by string import paths were considered too slow for #7688, it appears that the only alternative would be adapting wit-bindgen (e.g https://github.com/bytecodealliance/wasmtime/blob/61e1cdff5a90461ab8de471e100de5b824e079d1/crates/wit-bindgen/src/lib.rs#L810) to capture the indexes returned by LinkerInstance::resource calls in a table of some sorts returned by add_to_linker, if we still want to avoid the string lookups, that could be a nested struct type, where an index lookup could look something like this:

let idx = resource_definitions.wasi.io.poll.pollable

Alternatives

Allow string lookups for the RuntimeImportIndex as an alternative to the ResourceImportIndex computed at LinkerInstance::resource

view this post on Zulip Wasmtime GitHub notifications bot (Dec 20 2023 at 18:07):

rvolosatovs edited issue #7714:

Feature

With #7688 implemented it is now possible to take Resource<T> to ResourceAny, however the conversion does not work for resources provided by wasmtime_wasi crate, since the ResourceImportIndex is not exposed to the developer of those resources.

This is particularly important for dynamically-defined functions defined via Linker::func_new, which operate on wasmtime::Val directly. For example, it is currently not possible to return a wasi:io/poll/pollable resource from such a function without defining a custom wasi:io/poll/pollable implementation in the linker to acquire the import index to pass to try_into_resource_any in order to convert it to ResourceAny

Benefit

This allows dymanically-typed function definitions to operate on resources provided by WASI, i.e. it removes the need for developers using dynamically-typed functions utilizing WASI resources from reimplementing (parts of) WASI

Implementation

Since lookups by string import paths were considered too slow for #7688, it appears that the only alternative would be adapting wit-bindgen (e.g https://github.com/bytecodealliance/wasmtime/blob/61e1cdff5a90461ab8de471e100de5b824e079d1/crates/wit-bindgen/src/lib.rs#L810) to capture the indexes returned by LinkerInstance::resource calls in a table of some sorts returned by add_to_linker, if we still want to avoid the string lookups, that could be a nested struct type, where an index lookup could look something like this:

let idx = resource_definitions.wasi.io.poll.pollable

Alternatives

Allow string lookups for the RuntimeImportIndex as an alternative to the ResourceImportIndex computed at LinkerInstance::resource

view this post on Zulip Wasmtime GitHub notifications bot (Dec 20 2023 at 18:14):

rvolosatovs edited issue #7714:

Feature

With #7688 implemented it is now possible to take Resource<T> to ResourceAny, however the conversion does not work for resources provided by wasmtime_wasi crate, since the ResourceImportIndex is not exposed to the developer for those resources.

This is particularly important for dynamically-defined functions defined via Linker::func_new, which operate on wasmtime::Val directly. For example, it is currently not possible to return a wasi:io/poll/pollable resource from such a function without defining a custom wasi:io/poll/pollable implementation in the linker to acquire the import index to pass to try_into_resource_any in order to convert it to ResourceAny

Benefit

This allows dymanically-typed function definitions to operate on resources provided by WASI, i.e. it removes the need for developers using dynamically-typed functions utilizing WASI resources from reimplementing (parts of) WASI

Implementation

Since lookups by string import paths were considered too slow for #7688, it appears that the only alternative would be adapting wit-bindgen (e.g https://github.com/bytecodealliance/wasmtime/blob/61e1cdff5a90461ab8de471e100de5b824e079d1/crates/wit-bindgen/src/lib.rs#L810) to capture the indexes returned by LinkerInstance::resource calls in a table of some sorts returned by add_to_linker, if we still want to avoid the string lookups, that could be a nested struct type, where an index lookup could look something like this:

let idx = resource_definitions.wasi.io.poll.pollable

Alternatives

Allow string lookups for the RuntimeImportIndex as an alternative to the ResourceImportIndex computed at LinkerInstance::resource

view this post on Zulip Wasmtime GitHub notifications bot (Jan 08 2024 at 16:05):

alexcrichton commented on issue #7714:

I like the idea of the generated add_to_linker function returning a typed structure with *Index items inside of it myself. That seems like a nicely declarative route of communicating the result of all the add_to_linker calls.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 08 2024 at 16:46):

alexcrichton closed issue #7714:

Feature

With #7688 implemented it is now possible to take Resource<T> to ResourceAny, however the conversion does not work for resources provided by wasmtime_wasi crate, since the ResourceImportIndex is not exposed to the developer for those resources.

This is particularly important for dynamically-defined functions defined via Linker::func_new, which operate on wasmtime::Val directly. For example, it is currently not possible to return a wasi:io/poll/pollable resource from such a function without defining a custom wasi:io/poll/pollable implementation in the linker to acquire the import index to pass to try_into_resource_any in order to convert it to ResourceAny

Benefit

This allows dymanically-typed function definitions to operate on resources provided by WASI, i.e. it removes the need for developers using dynamically-typed functions utilizing WASI resources from reimplementing (parts of) WASI

Implementation

Since lookups by string import paths were considered too slow for #7688, it appears that the only alternative would be adapting wit-bindgen (e.g https://github.com/bytecodealliance/wasmtime/blob/61e1cdff5a90461ab8de471e100de5b824e079d1/crates/wit-bindgen/src/lib.rs#L810) to capture the indexes returned by LinkerInstance::resource calls in a table of some sorts returned by add_to_linker, if we still want to avoid the string lookups, that could be a nested struct type, where an index lookup could look something like this:

let idx = resource_definitions.wasi.io.poll.pollable

Alternatives

Allow string lookups for the RuntimeImportIndex as an alternative to the ResourceImportIndex computed at LinkerInstance::resource

Last updated: Oct 23 2024 at 20:03 UTC