-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Allow opaque but owning pointer indirection in bindgen'd types #3405
Comments
#[wasm_bindgen]
pub struct Connector {
#[wasm_bindgen(skip)]
pub hidden: Box<dyn Display>,
}
// or
#[wasm_bindgen]
pub struct Connector {
// note the lack of `pub`
hidden: Box<dyn Display>,
} |
Generally I'm more comfortable with having a type here instead of needing to tag each usage site with an attribute. Nevertheless, a wrapper with the attribute is probably also possible. It doesn't fully address the problem, however. As far as I understand, values of type But depending on that answer, should this issue also be changed to a documentation tag? There's no mention how The error message without the attribute suggests, that each attribute must individually be sendable via the ABI. I don't know how feasible it is to improve the error message if the attribute is 'forgotten'.
|
Not really. You could theoretically take all the object's state from Rust's memory and put it in a JS object, but that would mean having to copy it back again every time you want to call a method, since Rust can only operate on things inside its own memory. So, it'd be far less efficient. You might be thinking of the other 'heap' used by |
When returning a Rust value whose type has In effect, I'd like to take a Box's allocation directly and move the resulting pointer of it directly into In the above, the extra complexity via |
Motivation
In $business some core module is written in Rust. This module is then compiled to WASM in order to make the logic implemented in this this module accessible to a web-application. However, the primary goal is not to derive nor modify Javascript-state but rather that Javascript provides the IO-ful glue code to control the WebAssembly state via the web server. As such, the WASM state outlives any individual function invocation. (The executable model described this style as a ''reactor'').
We eagerly started by adding
#[wasm_bindgen]
sections and some connector handles to implement the interface. The idea was to retain a connector in JS which would call its methods when some event occurs, to send the appropriate state change to the module from outside its own main loop. But quickly noticed that there was a conflict: When the connector owns an attribute then this triggers bindgen to recursively require those attributes to also be sendable over the ABI. This is not what we want. The state we refer to is internal state which will be confined to the module and it contains several third-party types which may be impossible to defined as working with wasm-bindgen. Thus, the connectors can not refer to such internal (non-ABI-passed) state directly.An Indirection over some owning pointers is not easily possible, either. The standard containers (
Box
,Vec
) are only implemented for types that are introspectable, as well. The proposed solution is to change this and to provide standard inversions of reference types, so to speak.Proposed Solution
We want to be able to export strongly typed, owning handle instances from WASM. So, let's add non-ABI-recursive versions of
Box
,Arc
, etc. In our case, we did this via a macro since bindgen annotated types are also not yet allowed to be generic in any way.Macro definition for `mk_box`, an opaque `Box` equivalent.
Proposed usage
Alternatives
Within the
wasm-bindgen
library there are probably better alternatives:OpaqueBox<T>
might be added as a generic type with the same functionality.Box<T>
and similar types might be change to be opaque by default with dedicated types or other facilities to selective enable the structural nature of the ABI-translation attribute.Additional Context
Since the macro solution can be implemented as a library, it may be possible to provide full code (or a release) on request.
The text was updated successfully, but these errors were encountered: