You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When reading from a stream, it seems that the list that is returned from a stream is owned by the caller, but that is not clearly spelled out in the documentation.
The ownership of memory is not something specific to the wasi-http/wasi-io proposals, but rather defined by the Canonical ABI based purely on the types involved. For list<u8>, if you look at store_list in CanonicalABI.md, it describes how the core module's exported cabi_realloc function is called to allocate the memory, which is written into by the host, and then the pointer is returned to the core module. The C headers for the ownership semantics could be generated per-interface by wit-bindgen, though.
Improving documentation is a good idea, but I don't know if the Wit document is the right place since this ends up being for many guest/host languages, a bindings-internal detail (e.g., JS will simply see a JS array pop out). But perhaps this could be usefully generated as part of the ABI documentation or, perhaps better, in the generated C header comments. @sunfishcode was thinking about this too recently, so that we're not having to send folks to read Canonical ABI all the time.
In garbage collected languages, the ownership is clearly not as important, but in non-gc languages like C it is a question that someone asks whenever they see a pointer as a return value.
Even for explicitly-managed languages like C++/Rust, the ownership transfer should be made explicit in the return types of the generated bindings (e.g., a std::vector return-by-value). Also, when wasm-gc is integrated by adding new canonopts, the core wasm signature won't even return an i32 pointer, but rather some sort of wasm-GC reference type. Thus, this does seem to be something most appropriate in a generated C header file or perhaps a generated ABI doc.
Activity
lukewagner commentedon Mar 6, 2023
The ownership of memory is not something specific to the wasi-http/wasi-io proposals, but rather defined by the Canonical ABI based purely on the types involved. For
list<u8>, if you look atstore_listinCanonicalABI.md, it describes how the core module's exportedcabi_reallocfunction is called to allocate the memory, which is written into by the host, and then the pointer is returned to the core module. The C headers for the ownership semantics could be generated per-interface by wit-bindgen, though.brendandburns commentedon Mar 7, 2023
I was suggesting that the streams wit definition should add clarity in the comments about how this is expected to work.
lukewagner commentedon Mar 8, 2023
Improving documentation is a good idea, but I don't know if the Wit document is the right place since this ends up being for many guest/host languages, a bindings-internal detail (e.g., JS will simply see a JS array pop out). But perhaps this could be usefully generated as part of the ABI documentation or, perhaps better, in the generated C header comments. @sunfishcode was thinking about this too recently, so that we're not having to send folks to read Canonical ABI all the time.
brendandburns commentedon Mar 8, 2023
In garbage collected languages, the ownership is clearly not as important, but in non-gc languages like C it is a question that someone asks whenever they see a pointer as a return value.
lukewagner commentedon Mar 10, 2023
Even for explicitly-managed languages like C++/Rust, the ownership transfer should be made explicit in the return types of the generated bindings (e.g., a
std::vectorreturn-by-value). Also, when wasm-gc is integrated by adding newcanonopts, the core wasm signature won't even return ani32pointer, but rather some sort of wasm-GC reference type. Thus, this does seem to be something most appropriate in a generated C header file or perhaps a generated ABI doc.sw17ch commentedon Oct 8, 2026
The WASI HTTP champions looked at this in triage. WASIp3 streams, we believe, have solved or have ongoing work to solve all these issues.