wasmtime / issue #3633 Null `Memory` handle (and others) · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #3633 Null `Memory` handle (and others)

Wasmtime GitHub notifications bot (Jan 01 2022 at 19:54):

ZetaNumbers opened issue #3633:

Feature

Null value for stored types. Underlying data of handle types like Memory or Instance are owned by Store, so to operate on these handles you pass impl AsContext[Mut] as an argument. I think it would be useful to add a support for null handle types, which do not have any instance of Store they're handle to.

Benefit

I am trying to access memory inside of the import function. I am using import memory, so Caller::get_export is not an option. I could store Memory handle inside of the Store::data, but to instantiate memory handle you need the Store. I could use Option<Memory>, but for example Memory::read already panics if this memory doesn’t belong to store. So I thought perhaps more idiomatic way to solve this would be to create a dummy Memory for a dummy Store, create an actual Store with this dummy Memory inside, create an actual Memory using the actual Store, and replace the dummy Memory with an actual one. This process could be simplified if there was something like Memory::null.

Implementation

wasmtime::store::data::Stored<T> is used to create handles to a Store.

We could add Stored<T> null value. If store_id == 0 then it's null.

We could replace use of Stored<T> for Option<Stored<T>> and also focus impl<T> Index<Option<Stored<T>>> for StoreData. Perhaps also remove old interface like impl<T> Index<Stored<T>> for StoreData? Because Stored::<T>::store_id: NonZeroU64, size of Option<Stored<T>> is same as Stored<T>.

Alternatives

Perhaps something like <Store<T>>::map_data or RawStore without type params could also help my problem, if that's possible?

Wasmtime GitHub notifications bot (Jan 01 2022 at 22:41):

ZetaNumbers edited issue #3633:

Feature

Null value for stored types. Underlying data of handle types like Memory or Instance are owned by Store, so to operate on these handles you pass impl AsContext[Mut] as an argument. I think it would be useful to add a support for null handle types, which do not have any instance of Store they're handle to.

Benefit

I am trying to access memory inside of the import function. I am using import memory, so Caller::get_export is not an option. I could store Memory handle inside of the Store::data, but to instantiate memory handle you need the Store. I could use Option<Memory>, but for example Memory::read already panics if this memory doesn’t belong to store. So I thought perhaps more idiomatic way to solve this would be to create a dummy Memory for a dummy Store, create an actual Store with this dummy Memory inside, create an actual Memory using the actual Store, and replace the dummy Memory with an actual one. This process could be simplified if there was something like Memory::null.

Implementation

wasmtime::store::data::Stored<T> is used to create handles to a Store.

We could add Stored<T> null value. If store_id == 0 then it's null. Adds a null store concept.

We could replace use of Stored<T> for Option<Stored<T>> and also focus impl<T> Index<Option<Stored<T>>> for StoreData. Perhaps also remove old interface like impl<T> Index<Stored<T>> for StoreData? Because Stored::<T>::store_id: NonZeroU64, size of Option<Stored<T>> is same as Stored<T>.

Alternatives

Perhaps something like <Store<T>>::map_data or RawStore without type params could also help my problem, if that's possible?

Wasmtime GitHub notifications bot (Jan 01 2022 at 22:56):

ZetaNumbers edited issue #3633:

Feature

Null value for stored types. Underlying data of handle types like Memory or Instance are owned by Store, so to operate on these handles you pass impl AsContext[Mut] as an argument. I think it would be useful to add a support for null handle types, which do not have any instance of Store they're handle to.

Benefit

I am trying to access memory inside of the import function. I am using import memory, so Caller::get_export is not an option. I could store Memory handle inside of the Store::data, but to instantiate memory handle you need the Store. I could use Option<Memory>, but for example Memory::read already panics if this memory doesn’t belong to store. So I thought perhaps more idiomatic way to solve this would be to create a dummy Memory for a dummy Store, create an actual Store with this dummy Memory inside, create an actual Memory using the actual Store, and replace the dummy Memory with an actual one. This process could be simplified if there was something like Memory::null.

Implementation

wasmtime::store::data::Stored<T> is used to create handles to a Store.

We could add Stored<T> null value. If store_id == 0 then it's null. Adds a concept of a null store which cannot be accessed or instantiated.

We could replace use of Stored<T> for Option<Stored<T>> and also focus impl<T> Index<Option<Stored<T>>> for StoreData. Perhaps also remove old interface like impl<T> Index<Stored<T>> for StoreData? Because Stored::<T>::store_id: NonZeroU64, size of Option<Stored<T>> is same as Stored<T>.

Alternatives

Perhaps something like <Store<T>>::map_data or RawStore without type params could also help my problem, if that's possible?

Wasmtime GitHub notifications bot (Jan 01 2022 at 23:51):

ZetaNumbers edited issue #3633:

Feature

Null value for stored types. Underlying data of handle types (Global, Table, Func, Instance, Memory) are owned by Store, so to operate on these handles you pass impl AsContext[Mut] as an argument. I think it would be useful to add a support for null handle types, which do not have any instance of Store they're handle to.

Benefit

I am trying to access memory inside of the import function. I am using import memory, so Caller::get_export is not an option. I could store Memory handle inside of the Store::data, but to instantiate memory handle you need the Store. I could use Option<Memory>, but for example Memory::read already panics if this memory doesn’t belong to store. So I thought perhaps more idiomatic way to solve this would be to create a dummy Memory for a dummy Store, create an actual Store with this dummy Memory inside, create an actual Memory using the actual Store, and replace the dummy Memory with an actual one. This process could be simplified if there was something like Memory::null.

Adds a default constructor for these types in wasmtime-cpp bindings.

Implementation

wasmtime::store::data::Stored<T> is used to create handles to a Store.

We could add Stored<T> null value. If store_id == 0 then it's null. Adds a concept of a null store which cannot be accessed or instantiated.

We could replace use of Stored<T> for Option<Stored<T>> and also focus impl<T> Index<Option<Stored<T>>> for StoreData. Perhaps also remove old interface like impl<T> Index<Stored<T>> for StoreData? Because Stored::<T>::store_id: NonZeroU64, size of Option<Stored<T>> is same as Stored<T>.

Alternatives

Perhaps something like <Store<T>>::map_data or RawStore without type params could also help my problem, if that's possible?

Wasmtime GitHub notifications bot (Jan 02 2022 at 00:18):

ZetaNumbers edited issue #3633:

Feature

Null value for stored types. Underlying data of handle types (Global, Table, Func, Instance, Memory) are owned by Store, so to operate on these handles you pass impl AsContext[Mut] as an argument. I think it would be useful to add a support for null handle types, which do not have any instance of Store they're handle to.

Benefit

I am trying to access memory inside of the import function. I am using import memory, so Caller::get_export is not an option. I could store Memory handle inside of the Store::data, but to instantiate memory handle you need the Store. I could use Option<Memory>, but for example Memory::read already panics if this memory doesn’t belong to store. So I thought perhaps more idiomatic way to solve this would be to create a dummy Memory for a dummy Store, create an actual Store with this dummy Memory inside, create an actual Memory using the actual Store, and replace the dummy Memory with an actual one. This process could be simplified if there was something like Memory::null.

Adds ability to create these types inside of the const context (static definitions, const functions).

Adds default constructors for these types in wasmtime-cpp bindings.

Implementation

wasmtime::store::data::Stored<T> is used to create handles to a Store.

We could add Stored<T> null value. If store_id == 0 then it's null. Adds a concept of a null store which cannot be accessed or instantiated.

We could replace use of Stored<T> for Option<Stored<T>> and also focus impl<T> Index<Option<Stored<T>>> for StoreData. Perhaps also remove old interface like impl<T> Index<Stored<T>> for StoreData? Because Stored::<T>::store_id: NonZeroU64, size of Option<Stored<T>> is same as Stored<T>.

Alternatives

Perhaps something like <Store<T>>::map_data or RawStore without type params could also help my problem, if that's possible?

Wasmtime GitHub notifications bot (Jan 02 2022 at 00:23):

ZetaNumbers commented on issue #3633:

Implementation for the first method is partially complete on my fork.

Wasmtime GitHub notifications bot (Jan 02 2022 at 09:30):

ZetaNumbers edited issue #3633:

Feature

Null value for stored types. Underlying data of handle types (Global, Table, Func, Instance, Memory) are owned by Store, so to operate on these handles you pass impl AsContext[Mut] as an argument. I think it would be useful to add a support for null handle types, which do not have any instance of Store they're handle to.

Benefit

I am trying to access memory inside of the import function. I am using import memory, so Caller::get_export is not an option. I could store Memory handle inside of the Store::data, but to instantiate memory handle you need the Store. I could use Option<Memory>, but for example Memory::read already panics if this memory doesn’t belong to store. So I thought perhaps more idiomatic way to solve this would be to create a dummy Memory for a dummy Store, create an actual Store with this dummy Memory inside, create an actual Memory using the actual Store, and replace the dummy Memory with an actual one. This process could be simplified if there was something like Memory::null.

Adds ability to create these types inside of the const context (static definitions, const functions).

Adds default constructors for these types in wasmtime-cpp bindings.

Implementation

wasmtime::store::data::Stored<T> is used to create handles to a Store.

We could add Stored<T> null value. If store_id == 0 then it's null. Adds a concept of a null store which cannot be accessed or instantiated.

We could replace use of Stored<T> for Option<Stored<T>> and also focus impl<T> Index<Option<Stored<T>>> for StoreData. Perhaps also remove old interface like impl<T> Index<Stored<T>> for StoreData? Because Stored::<T>::store_id: NonZeroU64, size of Option<Stored<T>> is same as Stored<T>.

Alternatives

Perhaps something like <Store<T>>::map_data or RawStore without type params could also help my problem, if that's possible?

Anyway this is a marginal problem, so i could just use Option<Memory>.

Wasmtime GitHub notifications bot (Jan 02 2022 at 09:45):

ZetaNumbers commented on issue #3633:

After some thought, i think it's better to stick with Option<Memory>. Perhaps we could add a trait to implement Memory's interface on Option<Memory> too, but it feels like there's a lot more to explore with this design (like branded types). Perhaps the right path for now would be to add guard types, instead of having store: impl AsContext[Mut] argument on every function.

Wasmtime GitHub notifications bot (Jan 02 2022 at 11:01):

ZetaNumbers closed issue #3633:

Feature

Null value for stored types. Underlying data of handle types (Global, Table, Func, Instance, Memory) are owned by Store, so to operate on these handles you pass impl AsContext[Mut] as an argument. I think it would be useful to add a support for null handle types, which do not have any instance of Store they're handle to.

Benefit

I am trying to access memory inside of the import function. I am using import memory, so Caller::get_export is not an option. I could store Memory handle inside of the Store::data, but to instantiate memory handle you need the Store. I could use Option<Memory>, but for example Memory::read already panics if this memory doesn’t belong to store. So I thought perhaps more idiomatic way to solve this would be to create a dummy Memory for a dummy Store, create an actual Store with this dummy Memory inside, create an actual Memory using the actual Store, and replace the dummy Memory with an actual one. This process could be simplified if there was something like Memory::null.

Adds ability to create these types inside of the const context (static definitions, const functions).

Adds default constructors for these types in wasmtime-cpp bindings.

Implementation

wasmtime::store::data::Stored<T> is used to create handles to a Store.

We could add Stored<T> null value. If store_id == 0 then it's null. Adds a concept of a null store which cannot be accessed or instantiated.

We could replace use of Stored<T> for Option<Stored<T>> and also focus impl<T> Index<Option<Stored<T>>> for StoreData. Perhaps also remove old interface like impl<T> Index<Stored<T>> for StoreData? Because Stored::<T>::store_id: NonZeroU64, size of Option<Stored<T>> is same as Stored<T>.

Alternatives

Perhaps something like <Store<T>>::map_data or RawStore without type params could also help my problem, if that's possible?

Anyway this is a marginal problem, so i could just use Option<Memory>.

Last updated: Dec 06 2025 at 06:05 UTC