←back to thread

293 points kristoff_it | 2 comments | | HN request time: 0.477s | source
Show context
Retr0id ◴[] No.44609223[source]
I don't get it - the "problem" with the client/server example in particular (which seems pivotal in the explanation). But I am also unfamiliar with zig, maybe that's a prerequisite. (I am however familiar with async, concurrency, and parallelism)
replies(2): >>44609353 #>>44609377 #
koakuma-chan ◴[] No.44609353[source]
Example 1

You can write to one file, wait, and then write to the second file.

Concurrency not required.

Example 2

You can NOT do Server.accept, wait, and then do Client.connect, because Server.accept would block forever.

Concurrency required.

replies(2): >>44609387 #>>44610335 #
1. jayd16 ◴[] No.44610335[source]
But why is this a novel concept? The idea of starvation is well known and you don't need parallelism for it to effect you already. What does zig actually do to solve this?

Many other languages could already use async/await in a single threaded context with an extremely dumb scheduler that never switches but no one wants that.

I'm trying to understand but I need it spelled out why this is interesting.

replies(1): >>44610713 #
2. shikon7 ◴[] No.44610713[source]
The novel concept is to make it explicit where a non-concurrent scheduler is enough (async), and where it is not (async-concurrent). As a benefit, you can call async functions directly from a synchronous context, which is not possible for the usual async/await, therefore avoiding the need to have both sync and async versions of every function.

And with green threads, you can have a call chain from async to sync to async, and still allow the inner async function to yield through to the outer async function. This keeps the benefit of async system calls, even if the wrapping library only uses synchronous functions.