The suggestion of adding async / await to the language comes up with some frequency, with fibers being seen as a lackluster alternative.

Now, I feel like I must be missing something obvious, as fibers seem like the better option in almost every aspect to me. I'll compare them to async / await in .Net since that's the implementation I'm most familiar with.

The issues I have with a/a:

1. When a function wants to do something asynchronous every function up the call stack needs to be in on it. This is especially problematic with generic code and higher-order functions. Even with D's powerful metaprogramming facilities I don't see a way to handle this nicely. As an example: the whole IEnumerable / IAsyncEnumerable situation in .Net is a manifestation of this problem.

2. It messes up your callstack. This leads to problems with:

• Stack traces
• Debugging
• Memory dumps
• Sampling profilers
• And probably more that I haven't run into yet.

Now, some tooling can kinda sorta reconstruct a usable stack, but all the efforts I've seen so far are still harder to use than when you have a proper stack.

3. I don't like the Task<T> and await noise everywhere. It clutters up the code.

4. It's too easy to make a mistake and forget an await somewhere. Yes, an IDE will likely give a warning. No, I still don't like it ;)

5. It can put too much pressure on the GC. This won't be a problem when doing an HTTP request or something like that. It is a problem when there's an allocation for reading every single value in a DB query result.

All the above problems don't exist when using fibers. The only downside of fibers I'm aware of is that you have a full stack allocated for every fiber. This can cost a lot of (virtual) memory, but on the other hand it makes for very effective pooling. And if you're in a situation where this really is a problem you can tweak the stack size. Seems like a small price to pay to me.

Am I missing something? Thank you for your time.

On Wednesday, 11 May 2022 at 13:27:48 UTC, René Zwanenburg wrote:

You don't have to have a "Task" type that you declare, it could simply be T and then the function is just marked async and T automatically becomes Task!T.

The reason why C# doesn't do it that way is because they envisioned the ability to add your own Task types etc. but that has never been implemented or anything, so it's really just verbose.

It's easy to fix, don't allow implicit conversions between Task!T and T and thus whenever you attempt to use the result you're forced to await it because otherwise you'd get an error from the compiler due to mismatching types.

Like the below would definitely fail:

async int getNumberAsync();

...

auto number = getNumberAsync();

int otherNumber = 10 * number; // number cannot be used here due to it not being implicitly convertible to int. The fix would be to await getNumberAsync().

It doesn't really put anymore pressure on the GC. The compiler converts your code to a state machine and that hardly adds any overhead. It makes your functions somewhat linear, that's it. It doesn't require many more allocations, at least not more than fibers.

On Wednesday, 11 May 2022 at 13:27:48 UTC, René Zwanenburg wrote:

Don't forget that fibers aren't supported on all platforms.

They are definitely interesting but I don't think they should be the basis of everything.

On Thursday, 12 May 2022 at 08:49:18 UTC, Sebastiaan Koppe wrote:

That was one of my observations when I looked in the druntime source code. The D runtime has basically implemented all of the scheduling itself, including all context switching. This means that it has to be implemented for all architectures, and variants of all architectures which is a lot. Many platforms like Windows has its own fiber API and I was surprised that druntime didn't use that one.

I'm not saying that it is wrong to do the entire implementation in druntime but it is a lot of work and only the most common CPU architectures will be supported. There is also the risk that it becomes outdated as CPU vendors add stuff to their CPUs.

I think since the D project has such limited resources, it should go for as generic solutions and reuse existing APIs. Async/Await is becoming accepted as a programming model and I think that D should put its effort to support that.

On Thursday, 12 May 2022 at 06:04:06 UTC, bauss wrote:

That would help a little. Doesn't get rid of the await though.

Right. .Net doesn't do implicit conversion either, I was thinking of functions that are void / just Task, like writing to a database. Assuming you use exceptions to report problems.

Are you sure about this? The state machine needs to be stored somewhere. I'd think we would need something similar to a delegate: a fixed-size structure that can be passed around, with a pointer to a variable sized context / state machine living on the heap.