Closed loganek closed 1 year ago
IMO it's confusing to have a wit definition which is incompatible with README.md
i'd suggest to use a separate PRs for api/abi changes and introduction of a wit definition.
i'd suggest to use a separate PRs for api/abi changes and introduction of a wit definition.
This PR only changes WIT definitions. I don't think it's a problem for now to keep it like that; interfaces defined in README are somehow conceptual anyways, but I'm aiming to update them as well as soon as I confirm a couple of things related to WIT.
Since this proposal is currently using the instance-per-thread model, Wit isn't able to correctly describe it. thread-spawn
creates a new thread that implicitly captures the memory and imports of the calling thread, which is not something that Wit APIs can do. I suggest at least adding a comment about this.
which version of wit-bindgen (or other tools) can process this definition? i want to know the exact core wasm level abi corresponding to this definition.
This for now just defines types and has enigmatic documentation. The purpose of this PR is to reach agreement on type definitions:
result
as a return type for the function - that feels more idiomatic, although I presume that changes the C interface, so I'm curious to know what others thinkerrno
enum, which regardless of the decision about the point above, we might still keep to define types of errors being returned by the function. For now there's only eagain, but consider it as a placeholder. The point of this PR is not to define error codes, but to decide whether we want them as part of the public API or should we rather stick to binary response. IMO it feels reasonable to have them and we can define (better) set of errors than the ones in POSIXresult
,thread-id
can be an unsigned integer now, but the documentation should mention the reserved bits (or min/max value for thread id).