> You do not really await anything. What actually happens is an event handler gets called on an event,

So the event handler gets called immediately? No that’s not right. What would be the point of that? The event handler or continuation obviously needs to be scheduled on something that is awaitable. Meanwhile, other concurrent tasks may be able to run.

> This is the essence of asynchronous programming. There are no tasks, no yielding, practically no overhead and everything is deterministic

This is just totally wrong. Especially re tasks: https://docs.python.org/3/library/asyncio-task.html#creating...

There is nothing inherent about async and await that prevents “yielding”... the issue of yielding and semaphores is a concurrency issue and since async and await are used in concurrent programming environments, the same issues apply.

While it is true async and await don’t require any kind of cooperative concurrent framework to work, that is kind of their whole point for existing. A single task async/await system isn’t terribly interesting.

Like all “good” tech ideas this isn’t a terribly bad idea on its surface. It has no tech requirements. Running this just sounds like a nightmare. I really don’t want to be adminning griefing and trolling targeted at cancer patients.

Well run moderated communities for the dying are nothing new.

This is no different than async/await. At some point you await a scheduled primitive, it could be a timer, io readiness, an io completion... and yield to a scheduler. You don’t specify explicitly when you return. These are not tightly coupled coroutines. This is precisely what is going on in cooperative multitasking.

I don’t see how this increases overhead to deal with either.

Basically, coop multitasking and async/await operate on the exact same execution framework, the latter just gives convenient syntactic support.

Perhaps you should see how typescript turns async await into js.

> in one control is just given up and regained unpredictably

Which one? It’s “cooperative” ie not unpredictable. The points where one can block are predictable and documented explicitly, otherwise how would the programmer know they won’t block forever. The same should hopefully be the case for async/awaitable apis.

In fact where async/await will actually give up control are harder to tease out.

The differences are really not as big as they would seem.

He’s not getting swap. Or in a sense he is... you can still thrash.. the read only pages of the executable and any memory mapped files are still eligible to be paged out. When you get into a memory pressure situation you end up with a handful of executable pages of all the active programs getting faulted-in on every context switch.