Mention that the async model can be implemented using callbacks #424
Conversation
In the High-level Approach section, mention that the component model's approach to native async can also be implemented in terms of callbacks, in addition to language-level async, stackful coroutines, and green threads.
design/mvp/Async.md
Outdated
| @@ -63,6 +63,7 @@ over and can literally be implemented in terms of: | |||
| * stackful coroutines in languages like Kotlin, Perl, PHP and (recently) C++ | |||
| * green threads as-if running on a single OS thread in languages like Go and | |||
| (initially and recently again) Java | |||
| * callbacks, synchronous functions that are called in response to events | |||
There was a problem hiding this comment.
My understanding was that the first bullet point covered the callback case (i.e. their stackless async machinery would be implemented by way of persisting futures/promises/tasks to the heap so that the guest can return control to the host by returning from the exported function, and when the host calls the callback, the guest resumes the appropriate future/promise/task for that event). I imagine only C would expose the callback to application code directly; for other languages it would be a runtime implementation detail hidden from application code.
There was a problem hiding this comment.
But yeah, more words would make that much clearer.
There was a problem hiding this comment.
Could we merge this new bullet by extending the sentence of the old bullet: "async functions in languages like C#, JS, Python, Rust and Swift that can compile down to stackless callback functions that are called in response to events"?
There was a problem hiding this comment.
It seemed to me this list was written for the perspective of users of the languages, so in C#/JS/Python/etc. users get presented with async function bindings, in Kotlin/Perl/etc. users get bindings that use coroutines, in Go users get bindings that effectively use green threads. From that perspective, C with its exposed callbacks would be a separate bullet, rather than lumped in with async functions, even if they interface with the ABI using the same mechanism.
There was a problem hiding this comment.
Given that neither JS nor Python are (currently) compiled, I'd omit the "compile down to" phrase and say something like "async functions in languages like C#, JS, Python, Rust and Swift produce stackless tasks which may be resumed via callback functions that are called in response to events."
There was a problem hiding this comment.
@sunfishcode yes, that's reasonable, as long as we can make it clear that all the stackless languages are using the callback ABI under the hood.
BTW, we could even support both modes in C if desired: stackful (i.e. no callback functions) and stackless. The stackful mode would require guest toolchain (e.g. LLVM) support for (shadow) stack switching, of course.
There was a problem hiding this comment.
Ok, I've now added text that mentions that the stackless languages are using callback functions, and clarified the sentence that introduces the list.
In the High-level Approach section, mention that the component model's approach to native async can also be implemented in terms of callbacks, in addition to language-level async, stackful coroutines, and green threads.