Hum, in principle you can do arbitrary compile time transformations to the datagraph before submitting it via metaprogramming.

If you really want you could even convert the graph (fully or partially) to a runtime representation.

The core of the proposals are not about specific classes or functions other than some default algorithm implementations.

Instead they are mostly about defining concepts and protocols so that independent async domains can coexist and iteroperate in the same application.

This is similar to the STL where the most important part are the various iterator concepts and the algorithm interfaces, not the actual algo implementations and the containers.

> Hum, in principle you can do arbitrary compile time transformations to the datagraph before submitting it via metaprogramming.

I would find that to be great, but I don't understand how.

In e.g.

    while(i) {
        co_await sch.schedule(std::chrono::milliseconds(100));
        co_await w.write(--i);
    }

how can you get a meaningful "graph" object out of that, e.g.

[wait 100] -> [write 9] -> [wait 100] -> [write 8] -> ...

without actually "running" the code first to go through the co_await, which are the only way to acquire the information of what is to run ?

for instance, let's say that I want to compute "statically" (not in the "at compile time" sense but in the "after knowing the inputs to the program and before actually running the scheduler") how many [write] calls there are to schedule (assuming no cycles / infinite loops).

The proposed async "framework" happens to work well with coroutines, but they are not required (and infact most of the papers on the topic deal with them only in passing). You can build the async graph as an expression template and if you want, each operation (including the while loop) can be expressed as a different type.

I don't think coroutines provide (yet) enough introspection to break them down in the same way.

I see, that solves it then. Great !

> if we know that a set of tasks are dependent on each other in ways that aren't visible on the source code, but are known to the programmers, it would make sense to schedule them on a queue in their own thread

Why it would make sense?

In my experience, dedicated threads only makes sense in very specific use cases. Like dealing with APIs which have thread affinity, or when you want OS to prioritize stuff. Generally, throwing tasks into a shared thread pool is the way to go.

> In my experience, dedicated threads only makes sense in very specific use cases. Like dealing with APIs which have thread affinity, or when you want OS to prioritize stuff.

well, yes, those are things that happen fairly often. e.g. there's a lot of work on optimizing code for various arm big.LITTLE things, where you have some algorithm that you want to make sure runs on the "big" cores.

Can’t you use two shared thread pools, with threads affinity set to the big and little parts of the CPU, respectively?

I think for most use cases runtime scheduling is better than compile-time one. Because other processes sharing the hardware, and because tasks take unpredictable time, depends on almost everything including ambient temperature. Not to mention compilers don’t generally know count of cores, outside of a few niches like embedded, iOS and consoles games.

Could you please show an example for it?

In c++ some examples would be RaftLib or cpp-taskflow

> semi-reified asynchronous dataflow programming API based on coroutines

Gesundheit!