The claim is it "obsoletes the need for a traditional RTOS with kernel context switching."
I don't think the authors understand what an RTOS is, because it has very little to do with concurrency. It is about providing hard guarantees about execution timing of interrupt events. E.g. you need to poll an input port every 20ms, or something like that, because that's when the signal will be on the wire. Not "Please wait at least 20ms before resuming" but rather "I must resume execution in +0.020 sec from now with timing error constrained to no more than +/- 100 nanoseconds"
This is traditionally done by having an operating system with deterministic timing in its interrupt handling, so that it can schedule preemptive wake-up calls exactly when needed. As well as some important edge case handling like fast queueing of interrupts for later processing, or even dropping them entirely if a hard scheduled interrupt is being processed. Preemptive execution and OS threading is an absolute requirement.
Async rust doesn't even provide hard interrupts. It's cooperative multithreading so if some other event handler happens to be running when you need to resume, you're boned.
So AFAICT Embassy doesn't do this at all? In which case it doesn't "obsolete the need for a traditional RTOS with kernel context switching."
I haven't used Embassy, but the README mentions "Tasks on the same async executor run cooperatively, but you can create multiple executors with different priorities so that higher priority tasks preempt lower priority ones" and links to an example that shows how a higher priority task runs even though a lower priority one runs a long time job (does not yield), thus understanding and infrastructure seems to be there.
So, Embassy may in its entirety replace an RTOS / be one, but it's not the async mechanism that can provide the RT part (and I guess you're right to point out the dangerous sentence as it could mislead people to use only async and believe it's RT).
OTOH the sentence would be right if it were something like "async multitasking is an alternative to preemptive multitasking, and can replace the use of a preemptive OS if real-time guarantees are not needed (note that Embassy separately allows running multiple executors to allow to pre-empt tasks running in lower-priority executors)". They should probably also describe what the reason for not needing per-task stack size tuning is.
My perspective is that RT is not the most important thing for most or all of my projects. Concurrency on the other hand is very useful to me, and one of the main reasons I would need an RTOS. So for me embassy would potentially obselete the need. I agree that's not going to be the case for everyone though.
There isn't much difference between this and an OS. It's just that in an OS you switch between processes, whereas here they switch between async tasks. One could argue this is pretty semantic and that you could easily just call this an OS.
The claim is you can get embedded concurrency without an OS. Do you disagree?
I prefer C for embedded but must admit that's pretty compelling.
The claim is it "obsoletes the need for a traditional RTOS with kernel context switching."
I don't think the authors understand what an RTOS is, because it has very little to do with concurrency. It is about providing hard guarantees about execution timing of interrupt events. E.g. you need to poll an input port every 20ms, or something like that, because that's when the signal will be on the wire. Not "Please wait at least 20ms before resuming" but rather "I must resume execution in +0.020 sec from now with timing error constrained to no more than +/- 100 nanoseconds"
This is traditionally done by having an operating system with deterministic timing in its interrupt handling, so that it can schedule preemptive wake-up calls exactly when needed. As well as some important edge case handling like fast queueing of interrupts for later processing, or even dropping them entirely if a hard scheduled interrupt is being processed. Preemptive execution and OS threading is an absolute requirement.
Async rust doesn't even provide hard interrupts. It's cooperative multithreading so if some other event handler happens to be running when you need to resume, you're boned.
So AFAICT Embassy doesn't do this at all? In which case it doesn't "obsolete the need for a traditional RTOS with kernel context switching."
> So AFAICT Embassy doesn't do this at all?
I haven't used Embassy, but the README mentions "Tasks on the same async executor run cooperatively, but you can create multiple executors with different priorities so that higher priority tasks preempt lower priority ones" and links to an example that shows how a higher priority task runs even though a lower priority one runs a long time job (does not yield), thus understanding and infrastructure seems to be there.
So, Embassy may in its entirety replace an RTOS / be one, but it's not the async mechanism that can provide the RT part (and I guess you're right to point out the dangerous sentence as it could mislead people to use only async and believe it's RT).
OTOH the sentence would be right if it were something like "async multitasking is an alternative to preemptive multitasking, and can replace the use of a preemptive OS if real-time guarantees are not needed (note that Embassy separately allows running multiple executors to allow to pre-empt tasks running in lower-priority executors)". They should probably also describe what the reason for not needing per-task stack size tuning is.
My perspective is that RT is not the most important thing for most or all of my projects. Concurrency on the other hand is very useful to me, and one of the main reasons I would need an RTOS. So for me embassy would potentially obselete the need. I agree that's not going to be the case for everyone though.
There isn't much difference between this and an OS. It's just that in an OS you switch between processes, whereas here they switch between async tasks. One could argue this is pretty semantic and that you could easily just call this an OS.
If it has async and concurrency isnt this an OS?