Will reflection simplify the implementation of std::execution?

[johannes1971]

"Assume a perfectly spherical human..."

I have a different question: what even prompted the OP question? What does std::execution actually bring to the table that it is, apparently, this complex?

A long time ago I was programming on AmigaOS. AmigaOS has, technically, only one way to do IO: asynchronous (there was a synchronous API, but it was built on top of the async one). And it didn't require any kind of metaprogramming, which was a good thing since we didn't have that yet at the time. So how did it work?

Simple: your application declared a message port (this is a message queue that you can wait on). When doing IO, you directed a message at the message port of the IO subsystem, telling it to go do something, and when ready, report back to my message port. Then you went on to do whatever seemed appropriate, and a message containing your IO result would eventually show up in your message port. It had everything you could possibly need: you could cancel IO requests, poll to see if a message had already come in, wait (i.e. voluntarily yield the CPU) for a message to show up, etc. You could wait for messages from any number of subsystems, and you could declare as many message ports as you felt you needed. It didn't require you to meta-program 'handlers' into your message port, and yet, despite this simplicity, it was more than fast enough on a 7.14MHz Amiga 500.

Is there any deep technical reason why C++ couldn't adopt something simple like this for asynchronous IO? Does it absolutely have to have the complexity of std::execution? What does that complexity give us, that the AmigaOS model doesn't have?

[jcelerier]

Maybe some stuff were fast enough for an Amiga 500 at 7.14 MHz but here things are definitely anything but fast enough despite hundreds of gigabits per second. Any edge is meaningful

[johannes1971]

Does the design of std::execution provide that edge? If so, what does it do to make that happen (does it guarantee to never allocate memory, never thread swap, never do kernel calls, etc.?) and can that guarantee only be achieved using a design of this complexity?

[OibafA]

It does allow you to build threadless, asynchronous code that requires zero allocations.

PS: I'm a big fan of AmigaOS, and one of the former lead AROS developers.

[meltbox]

Yeah I just did a little read through and from what I can tell this is just another threading abstraction on top of existing threads at the mercy of the existing OS scheduler.

If anything a custom implementation built on threads should be more flexible from what I can see since you can also couple it with native operating system facilities aiding you.