From e04af86491d97b297406cc4cd0d77fbbfc3a94c4 Mon Sep 17 00:00:00 2001 From: JJ Date: Thu, 16 May 2024 17:40:34 -0700 Subject: docs: update website --- docs/book/ASYNC.html | 26 +++++--------------------- 1 file changed, 5 insertions(+), 21 deletions(-) (limited to 'docs/book/ASYNC.html') diff --git a/docs/book/ASYNC.html b/docs/book/ASYNC.html index af56864..aa1ddf7 100644 --- a/docs/book/ASYNC.html +++ b/docs/book/ASYNC.html @@ -7,7 +7,7 @@ - + @@ -190,12 +190,12 @@ let c: T = await async fetch_html() ... todo ...
pub func await[T](self: Future[T]): T =
- while not self.ready:
- block
+ while not self.ready do
+ # block
self.value! # apply callbacks?
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.
+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?
References: