Google is developing an OS called “Fuchsia,” runs on All the Things (Android Police)

> In BeOS what _everybody_ actually did was divide their app into essentially two parts.

Isn't this a bit like how a good Android app is structured? i.e. one or more disposable Activities implementing the UI behaviour and screens, with some Service persiting in the background to do any heavy lifting or long running work?

> And on the surface this seems to work really well, very responsive. But just below the surface you realise that your app is stalled just the same as the equivalent app on Windows or any other OS, except that the UI is "responsive" in the sense that you can still click on buttons and there's no busy cursor.

In this example, you have a poorly programmed app. The UI could quite happily display a busy cursor while it waits on the lower priority backend to complete some task - if the app has been programmed to do so. Nothing about the split architecture prevents use of busy cursors or other visual user feedback. The difference with one big event loop is that the UI stops responding, even maybe stopping repainting, and is effectively frozen while some other activity completes (e.g. a trivial disk access which may be held up due to some other heavy disk load). This can look glitchy and laggy to the user.

With a split foreground/background type of achitecture, using different threads for each processing, you also have to option to offer the user 'canel operation' or 'abort' operations which can be handled by the foreground UI thread to dispatch a message to the background task to stop it (granted the background task may need to poll it's message queue or similar to pickup that it should stop.

Given today's mobile apps seem to be all about having whizzy UIs with lots of smooth animations, scrolling, transitions and other eye-candy, the BeOS approach you describe maybe appropriate.

IMHO the reason why it was responsive is that their first harware target was a dual core computer, so they wrote applications really using multiple threads and it felt very responsive even on single core CPU, nice!

The only real reason I would say 'why bother reproducing what BeOS did' is SSD, now with SSD even normal OS seems responsive..
That said I wonder how Haiku would feel on a SSD equipped computer..

Hard real time just means that certain nominated jobs (sometimes all jobs, for simpler systems used in predictable ways) have a guaranteed bound to their worst case execution time. Whatever reason you might have for wanting that is orthogonal.

>Let's try to not to redefine words - otherwise there is no sensible discussion if "real time" just means "very fast, consumes only very few resources, basically flawless".

Nobody said that.

And to me, there's no difference between water and potato, and the "Attack of the Snarblefarx" was the greatest film that Orson Welles ever made, and anyone who doesn't agree that blue tastes hot is clearly deaf.

I demand that you use my definitions of these words, because to me they're correct, and the only way it could be otherwise would require changing the fundamental laws of physics.

Is this reverse² polish notation for factorial?

You want the UI to do what exactly? Give you an answer within 20ms, and you are not accepting „I’ll get back to you“ as an intermediate response? If I understood you correctly, you don’t want a RTOS, you want a magic wand.

Correct. The CPU runs at it's clock rate, which isn't a function of OS type.

> To have this 'real time performance' you have to pre-empt things continuously.
> The more of these interrupts that you have then the worse the performance gets. The more 'things' you are doing the more interrupts you need and the worse performance gets.

Nope. You have to pre-empt things when _necessary_ in an RTOS, and only that. You might be thinking of time-slicing schedulers using a tick, which RTOSes generally don't do (though some offer configuration for time slicing priority levels if needed). More generally in a fully pre-emptive priority based system, processes run until one of two things happens, either a) a higher priority task becomes ready to run or b) the current process blocks to allow the next highest priority task to run. A context switch, with it's overhead, is needed in both these cases. Case a) occurs either when an interrupt comes in and unblocks a higher priority task (this could be a peripheral or a hardware timer interrupt triggering a higher priority task), or the current task directly unblocks a higher priority task (e.g. by posting a message to it, or releasing some shared lock/semaphore). Interrupts happen as and when needed, but the unblocking of higher priority tasks is in the control of the system architect/designer/programmer. Case b) generally means that the current task has completed it's useful work and is now idle.

Compared with a 'tick' based time sliced scheduler, an RTOS scheme may be reasonably efficient and not need any tick interrupt at all. With careful design, tasks can easily perform a unit of processing and run to completion without ever being pre-empted, which is most cache efficient. Bad design with an RTOS can have lots of overhead though, particularly if a low priority task continually enables a higher priority task and causes excessive context switching back and forth.

Like all things, there is no silver bullet, but an RTOS gives the programmer control and predictability over when context switches occur, and as such, good and bad designs can be implemented with corresponding performance gains or losses. With time-slicing schedulers, you just have constant overhead of a regular tick, except in the special cases that there is only 1 runnable task on a CPU or the CPU is idle and the scheduling tick can be disabled. With time slicing, the OS picks your scheduler tick rate to be between high (lower latency but more context-switch overhead) and low (better for bulk processing, but more latency). With an RTOS, the design and architecture of the task set determines the context switch rate.

> When you combine that with the fact that userland applications in Android are programmed using VM-using GC-using language and cannot be predictably schedualed anyways... then you lose any benefit you have to having a real RTOS system.

Yeah - this is a good point. You can write native apps for Android, and parts of Android are undoubtedly using native libs for things like media codecs, display drivers and hardware supervision which may benefit from an RTOS. But actually, almost all SoCs will come with a Linux BSP for this stuff so it's at huge cost to move these things to an RTOS. Either Google see other benefits as well, or this is them trying something else to keep options open.

A bit of serious competition in the OS space can only be good though.