Take this issue with a grain-of-salt.
I've noticed that the current (I understand it's a work in progress) wasi api for polling is similar to modern epoll in many ways. Perhaps, implementations that use wasi's polling api (which will presumably be many/most of them) would be simpler if we adopted a simpler, easier to write against api that mirrors that of rust's futures.
I propose that we export a function called register_callback to modules that has the following signature:
(type $t6 (func (param i32 i64 i32) (result i32)))
In rust, that would be:
extern {
fn register_callback(handle: u32, key: u64, f: extern fn(u64)) -> u32;
}There would be supporting machinery around it, but essentially, you'd register an event--on a socket for instance--to this handle value, and then register a callback associated with it. The key parameter is passed, unchanged, to the callback when the event occurs.
The callback would, at the wasm level, be the index of an exported function.
I think this would integrate quite directly with rust's Futures and other languages' async internals, though I haven't tried it of course. Plus, it would likely reduce the amount of async machinery a module would have to carry around with it by a very significant amount.
There's an important unanswered question: Would this callback be called on a separate thread by the runtime (sort of like a signal), meaning that it would have to use atomic instructions to interface with the module's memory, or would the module have to relinquish control to the runtime for the callbacks to start being called in a single-threaded manner?
Take this issue with a grain-of-salt.
I've noticed that the current (I understand it's a work in progress) wasi api for polling is similar to modern epoll in many ways. Perhaps, implementations that use wasi's polling api (which will presumably be many/most of them) would be simpler if we adopted a simpler, easier to write against api that mirrors that of rust's futures.
I propose that we export a function called
register_callbackto modules that has the following signature:In rust, that would be:
There would be supporting machinery around it, but essentially, you'd register an event--on a socket for instance--to this
handlevalue, and then register a callback associated with it. Thekeyparameter is passed, unchanged, to the callback when the event occurs.The callback would, at the wasm level, be the index of an exported function.
I think this would integrate quite directly with rust's Futures and other languages' async internals, though I haven't tried it of course. Plus, it would likely reduce the amount of async machinery a module would have to carry around with it by a very significant amount.
There's an important unanswered question: Would this callback be called on a separate thread by the runtime (sort of like a signal), meaning that it would have to use atomic instructions to interface with the module's memory, or would the module have to relinquish control to the runtime for the callbacks to start being called in a single-threaded manner?