rvolosatovs opened issue #7714:
Feature
With #7688 implemented it is now possible to take
Resource<T>
toResourceAny
, however it does not work for resources provided bywasmtime_wasi
crate, since theResourceImportIndex
is not exposed to the developer of those resources.
This is particularly important for dynamically-defined functions defined viaLinker::func_new
, which operates onwasmtime::Val
directly. For example, it is currently not possible to return awasi:io/poll/pollable
resource from such a function without defining a customwasi:io/poll/pollable
implementation in the linker to acquire the import index to pass totry_into_resource_any
in order to convert it toResourceAny
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 byLinkerInstance::resource
calls in a table of some sorts returned byadd_to_linker
, if we still want to avoid the string lookups, that could be a nestedstruct
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 theResourceImportIndex
computed atLinkerInstance::resource
rvolosatovs edited issue #7714:
Feature
With #7688 implemented it is now possible to take
Resource<T>
toResourceAny
, however the conversion does not work for resources provided bywasmtime_wasi
crate, since theResourceImportIndex
is not exposed to the developer of those resources.This is particularly important for dynamically-defined functions defined via
Linker::func_new
, which operates onwasmtime::Val
directly. For example, it is currently not possible to return awasi:io/poll/pollable
resource from such a function without defining a customwasi:io/poll/pollable
implementation in the linker to acquire the import index to pass totry_into_resource_any
in order to convert it toResourceAny
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 byLinkerInstance::resource
calls in a table of some sorts returned byadd_to_linker
, if we still want to avoid the string lookups, that could be a nestedstruct
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 theResourceImportIndex
computed atLinkerInstance::resource
rvolosatovs edited issue #7714:
Feature
With #7688 implemented it is now possible to take
Resource<T>
toResourceAny
, however the conversion does not work for resources provided bywasmtime_wasi
crate, since theResourceImportIndex
is not exposed to the developer of those resources.This is particularly important for dynamically-defined functions defined via
Linker::func_new
, which operate onwasmtime::Val
directly. For example, it is currently not possible to return awasi:io/poll/pollable
resource from such a function without defining a customwasi:io/poll/pollable
implementation in the linker to acquire the import index to pass totry_into_resource_any
in order to convert it toResourceAny
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 byLinkerInstance::resource
calls in a table of some sorts returned byadd_to_linker
, if we still want to avoid the string lookups, that could be a nestedstruct
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 theResourceImportIndex
computed atLinkerInstance::resource
rvolosatovs edited issue #7714:
Feature
With #7688 implemented it is now possible to take
Resource<T>
toResourceAny
, however the conversion does not work for resources provided bywasmtime_wasi
crate, since theResourceImportIndex
is not exposed to the developer for those resources.This is particularly important for dynamically-defined functions defined via
Linker::func_new
, which operate onwasmtime::Val
directly. For example, it is currently not possible to return awasi:io/poll/pollable
resource from such a function without defining a customwasi:io/poll/pollable
implementation in the linker to acquire the import index to pass totry_into_resource_any
in order to convert it toResourceAny
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 byLinkerInstance::resource
calls in a table of some sorts returned byadd_to_linker
, if we still want to avoid the string lookups, that could be a nestedstruct
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 theResourceImportIndex
computed atLinkerInstance::resource
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 theadd_to_linker
calls.
alexcrichton closed issue #7714:
Feature
With #7688 implemented it is now possible to take
Resource<T>
toResourceAny
, however the conversion does not work for resources provided bywasmtime_wasi
crate, since theResourceImportIndex
is not exposed to the developer for those resources.This is particularly important for dynamically-defined functions defined via
Linker::func_new
, which operate onwasmtime::Val
directly. For example, it is currently not possible to return awasi:io/poll/pollable
resource from such a function without defining a customwasi:io/poll/pollable
implementation in the linker to acquire the import index to pass totry_into_resource_any
in order to convert it toResourceAny
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 byLinkerInstance::resource
calls in a table of some sorts returned byadd_to_linker
, if we still want to avoid the string lookups, that could be a nestedstruct
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 theResourceImportIndex
computed atLinkerInstance::resource
Last updated: Dec 23 2024 at 12:05 UTC