I've actually been looking for something like this to translate over to zig. Thanks for sharing! The only thing it seems to be missing for my purposes is a way of returning a value.
Yeah I'm seeing the sync functions, since those should wait till the task is finished any returned value should be able to be received at that point. Even a future promise system should be possible since it's basically just a pointer to an object with a flag saying if the object has been returned yet or not.
I'm not going to press someone else to do it though, I'm just gonna implement it myself since I have to rewrite it all anyways.
You can pass a reference to a something that the task should update as one of its arguments (e.g. a pointer to a place in memory big enough for a pointer that starts out as null). Then wait for the task. Then check what it left you at the reference. It's the world's most boring channel.
Those are objects. It should be possible to nest tasks without introducing object-oriented abstractions. If that isn't possible with this library, then I agree with the original commenter that it's kind of a missing feature.
Promise/future/channels are implemented as objects in OO languages. But there are non-OO languages that have them (futures/promises, for sure), and they aren’t objects there.
That's true, Rust has futures and those aren't objects, they're just state machines. However, "awaiting" a future causes it to execute nested inside your own, not as a new task, so it doesn't act as a traditional promise/future. I'm pretty sure GGP was referring to the OOP concept.
Promises in, say, JavaScript, represent the eventual outcome of an asynchronous computation. When you call an asynchronous function, it starts immediately and you get a Promise for it. Asynchronous callers can then await this Promise to give the impression that they're performing a sub-computation, but technically they are just waiting on a new separate task. Futures in, say, Kotlin, are the same thing, and channels are how both of these are typically implemented.
Those kinds of Promises require some bookkeeping that's not free. While it's helpful to be able to just pass around "the eventual outcome of a specific task", that's not actually needed for asynchronous functions to be able to return values. You just need a way for the function to execute nested within another without necessarily requiring a new task.
I've taken a look at OP's library, and it seems to be lower-level than yielding. That means either one of these paradigms can probably be built on top of it. I take back my statement that it's a missing feature, I thought this library was meant to do more than it does.
How would you propose to implement returns from an async code? Do you have examples of any async code returning values without “objects” or compiler magic? There’s probably some c trickery I’m not aware of! As I’m not familiar with c, I look forward to learning a new thing.
I think it is the wording, semantics. Replace “return” with “emit” and it all holds up.
> Do you have examples of any async code returning values without “objects” or compiler magic?
Lua coroutines represent a yieldable computation, but given a coroutine object, you can't await it or retrieve a return value from it. The only things you can do with a coroutine are check its status and resume it. So how do asynchronous computations return values in Lua?
It's simple: don't create an extra coroutine around it. If you're already in a yieldable coroutine, then you can call the yielding function directly. Nested yields will bubble up, and from the caller's perspective you just call a function and it returns a value.
Doing this from Lua is a bit of compiler/interpreter magic, but some modified Lua interpreters support yieldable C functions that can also perform yieldable calls [0]. This requires some due diligence on the part of the caller, making sure to bubble up yields from the inner function and also pass down resumes until it completes (you need to add a state for "this function call yielded"). But it uses no promises, futures or channels.
Of course, you can create a coroutine that wraps a yielding function and notifies a channel or callback once it's done. Those just aren't part of the language and aren't actually necessary for multitasking.
Presumably you're supposed to include space for that as part of the argument when you construct the task in the first place, then just run until the task is complete. Given the awkwardness of returning bigger-than-pointer types anyway, this is actually easier than the alternative.
That said, the API here is undocumented and the chosen names are very confusing (implementations do not do what I would expect functions of those names to do).