Comment by osa1
By CPS do you mean lightweight threads + meeting point channels? (i.e. both the reader and writer get blocked until they meet at the read/write call) Or something else?
Why is CPS better and lower level than async/await?
By CPS do you mean lightweight threads + meeting point channels? (i.e. both the reader and writer get blocked until they meet at the read/write call) Or something else?
Why is CPS better and lower level than async/await?
This was my point. With Go it does not matter, i can do IO or CPU both with Gos concurrency (CSP), but with async/await i usully cannot, i assume this is not something Zig is planning on, as it seems to be all about IO.
Because it allows multiple topologies of producers and consumers.
I believe async/await means you have a single consumer (caller) and a single producer (callee) and only a single value will be produced (resolved).
With CPS you may send and receive many times over to whomever and from whomever you like.
In JavaScript you may write..
const fetchData = async () => {
// snip
return data;
}
const data = await fetchData();
channel := make(chan int);
go func() {
// snip
channel <- data;
}()
data := <-channel
go func() {
for { // Infinite loop:
// snip
channel1 <- data;
channel2 <- data;
channel3 <- data;
}
}()
Async/await tend to be IO bound, in zigs case hiw can i know what to use and when? Say i do a db call, thats clearly IO, and later do heavy CPU thing, now how do i know that the CPU thing does not block inside my async io thing?
I guess its pure luck if the io implementation can handle both, but who knows?