WebAssembly / WebAssembly/WASI
inconsistent future resource ownership
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 5.8k
- Forks
- 333
- Avg merge
- 2d 13h
- Merged PRs (30d)
- 3
Description
Hi! I noticed that the future-trailers has some extra introduction than future-incoming-response:
... and the resource must be dropped before the parent
future-trailersis dropped.
This seems a bit impractical from the client side, as this means that we need somehow keep track of the future-trailers even when it is ready and the internal resource is retrieved. Also I wonder if this is a mistake because I saw this PR as it mentions:
This gives implementations the flexibility to transfer ownership of the resulting trailers out of the future-trailers resource.
I'd like to confirm whether this statement is still true on current implementations?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Compare the future-trailers and future-incoming-response definitions in wit/types.wit, especially the ownership wording around the linked line. Read the ownership discussion in PR #86 and determine whether current implementations support transferring the resulting trailers; done means resolving the inconsistency and specifying the intended behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- wasm
- Domain
- api, operating-systems
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100