aboutsummaryrefslogtreecommitdiff
path: root/docs/ASYNC.md
diff options
context:
space:
mode:
Diffstat (limited to 'docs/ASYNC.md')
-rw-r--r--docs/ASYNC.md6
1 files changed, 5 insertions, 1 deletions
diff --git a/docs/ASYNC.md b/docs/ASYNC.md
index ec610ca..87c602d 100644
--- a/docs/ASYNC.md
+++ b/docs/ASYNC.md
@@ -29,11 +29,15 @@ pub func await[T](self: Future[T]): T =
This implementation differs from standard async/await implementations quite a bit.
In particular, this means there is no concept of an "async function" - any block of computation that resolves to a value can be made asynchronous. This allows for "anonymous" async functions, among other things.
+This (packaging up blocks of code to suspend and resume arbitrarily) is *hard*, and requires particular portable intermediate structures out of the compiler. Luckily, Zig is doing all of the R&D here. Some design decisions to consider revolve around *APIs*. The Linux kernel interface (among other things) provides both synchronous and asynchronous versions of its API, and fast code will use one or the other, depending if it is in an async context. Zig works around this by way of a known global constant that low-level functions read at compile time to determine whether to operate on synchronous APIs or asynchronous APIs. This is... not great. But what's better?
+
<!-- Asynchronous programming is hard to design and hard to use. Even Rust doesn't do a great job. It *shouldn't* need built-in language support - we should be able to encode it as a type and provide any special syntax via macros. Note that async is not just threading! threading is solved well by Rust's rayon and Go's (blugh) goroutines. -->
## Threading
-How threads work deserves somewhat of a mention. todo
+It should be noted that async is *not* the same as threading, *nor* is it solely useful in the presence of threads...
+
+How threads work deserves somewhat of a mention...
References:
- [What color is your function?](https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/)