Though I might nitpick the introduction:
One of the main promises of asynchronous, parallel processing is that it can increase overal [overall] performance of your program.
Apart from the spelling error, this seems a bit vague to me.
concurrent processing generally described as two or more processes start, run in an interleaved fashion through context switching.
parallel processing where two or more processes actually run at the same time on different cores/machines.
Clearly concurrent processing will lower overall performance thanks to all that added context switching. Only parallel processing can add performance, by actually getting more hardware on the job. But it too suffers from the overheads of scheduling and communicating between tasks.
Then we have
asynchronous programming which is kind of orthogonal to either of the above and may make use of both.
The promise of
asynchronous programming then, in my view, is to claw back the resources and performance lost to having lots of task contexts and the resulting context switching.
As someone nicely put it "Synchronous processing is for when you have a lot of work to do, async is for when you have a lot of waiting to do"
The Rust Async Book notes:
It's important to remember that traditional threaded applications can be quite effective, and that Rust's small memory footprint and predictability mean that you can get far without ever using
async . The increased complexity of the asynchronous programming model isn't always worth it, and it's important to consider whether your application would be better served by using a simpler threaded model.
Having said all that....
I think the idea of an operating system on the Raspberry Pi, or pretty much anywhere, that supports non-blocking system calls and async programming throughout is an excellent idea.