-
Notifications
You must be signed in to change notification settings - Fork 247
Description
Currently wit_bindgen::rt::async_support contains a FutureWaker type used to determine whether to return CALLBACK_CODE_YIELD or CALLBACK_CODE_WAIT when the Future corresponding to a given task returns Poll::Pending. However, it ought to be a bit smarter with regards to inter-task communication.
Consider a scenario involving two concurrent tasks: A and B:
- A creates a oneshot channel and stores the write end in a global variable, then
awaits the read end, returningCALLBACK_CODE_WAITto the host - B writes to the write end, waking A's waker
In this case, waking A's waker should have the effect of telling the host to resume A; currently it does not. I imagine the waker could create a new payload-less future, call future.read on the read end (which would return RETURN_CODE_BLOCKED), add the read end to A's waitable-set, then call future.write on the write end, causing the host to eventually call the callback for A. Alternatively, we could either proactively or lazily create a payload-less stream for each task and reuse it as needed. Once we have cooperative multithreading support, we could simplify that to just calling e.g. thread.switch-to -- no future or stream needed.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status