-
Notifications
You must be signed in to change notification settings - Fork 194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ownership of resource handles #148
Comments
I think this is probably best addressed at the interface-types layer rather than wit-bindgen here. There's not really a way to simply tweak codegen to remove I believe what you want for your use case is a Rust-like owned resource and perhaps a borrowed resource as well. We've discussed this internally in the past but they haven't ever gotten over the finish line to the point of being spec'd and implemented. For now I'd recommend opening an issue on the interface-types repository to track the feature request. |
|
I am currently working on a small side project that will need the new |
Resources are pretty high up on the list of things to do, but I don't have a timeline for when they'll be done. Work on resources will span many repositories and many aspects of the design an implementation, so unfortunately I don't know of a great way to have the work spread out amongst many at this time. |
I'm would like to use wit to generate host/wasmtime and guest/rust bindings for lunatic. However, I'm still not sure how to correctly model a specific use case.
In lunatic some of the host resources can be sent between different instances. This means that they are consumed by some host functions and removed from the resource table. This doesn't work well with the current Canonical ABI proposal that requires all resources to expose a
clone
anddrop
API and implies reference counting.One workaround is to keep the host resource inside of an
Option<T>
and remove it once it needs to be sent to another instance. Then on every invocation of a host function dealing with the resource check if the value isSome(T)
. This works okish.The bigger issues here is that the guest side generated code also generates a
Clone
andDrop
implementation. We would like to avoid exposing theClone
functionality to developers though. It would make the API better reflect the underlaying properties of the resource. Is there a way of disabling thisClone
option, and ideally not even use reference counting inside of the host in this case?I guess my question i more general. How to handle this specific scenario with interface types, when the function "consumes" the resource?
I also feel like I didn't completely understand the difference between a resource and a resource handle. Maybe the automatic cloning can be avoided if using resources directly, instead of handles?
The text was updated successfully, but these errors were encountered: