Re: Forth as an operating system
- From: Bernd Paysan <bernd.paysan@xxxxxx>
- Date: Mon, 03 Dec 2007 14:46:26 +0100
Keith H Duggar wrote:
And will this team ever make a mistake? And if they do,
what can happen under a cooperative task manager? Suppose
a bug makes it past review and testing into a production
system. Suppose that bug results in failure to yield. What
Ok, let's rephrase the question: Under a preemtive multitasker, you probably
need semaphores you don't for a cooperative multitasker (because in the
cooperative multitasker, everything between two PAUSEs is atomic).
Semaphores have the problem of deadlocks, and if you forget them, race
conditions are possible. Suppose your team B introduces a deadlock or race
condition. What happens? Or what happens on a memory leak?
One way around is to add some watchdog functionality. A watchdog can kill
and restart an application that fails to yield or deadlocks. An out of
memory killer can help with memory leaks (by restarting the worst
offender). This all has nothing to do with cooperative or preemptive; if
you let bugs like this happen, you must take counter-actions as described.
You can do nothing against race conditions, since there's no automatic to
There's another problem, that's memory protection. Memory protection is
nice, since you can shield applications from each others. So at least you
know when an application breaks, it must have either been buggy from start,
or it had corrupted its own memory. Unfortunately, an application
corrupting its own memory is already bad enough. To make a system reliable
and secure, no application is permitted to corrupt its own memory. Once you
allow students and idiots to run their own selection of programs (which
then become mission critical), game over, you lost.
The bottom line of this is that people try to shield programs even more.
Virtualization is the buzzword of the year. It's actually a consolidation,
since people have put each service onto another box to shield all the
broken services from each others.
I think there are two different schools at work here. The conventional
school identifies typical bug sources and then tries to automatically
prevent them, by adding complexity on every level (hardware, OS, compiler).
The Forth school knows about the typical bug sources, but does not try to
prevent them by adding complexity, because complexity is perceived as an
evil of its own.
There are other, similar differences. E.g. how to deal with idiots who
participate in a computer programming team. The Forth school advice: Don't
let idiots touch the program code, maybe they can perform tests or talk to
idiotic customers (but don't give them any influence into technical
The common advice however is: Use tools that let even idiots write programs.
As a consequence, the good programmers are dumbed and slowed down, and as
additional task, they also have to interface with idiotic parts of the
program (idiots neither write good interfaces nor good programs). Using the
good programmers up to write the interfaces and define the architecture
only is of limited help, since idiots can't make good use of a nicely
defined interface or architectures, either, and even good programmers tend
to write bad interfaces/architectures if they don't implement the code
behind, as well.
"If you want it done right, you have to do it yourself"
- Re: Forth as an operating system
- From: jpd
- Re: Forth as an operating system
- Prev by Date: Re: RfD: Escaped Strings S\" (version 5)
- Next by Date: Re: Forth as an operating system
- Previous by thread: Re: Forth as an operating system
- Next by thread: Re: Forth as an operating system