One of the basic jobs of an operating system is to coordinate between different processes/threads. The two basic choices are cooperative multitasking and pre-emptive multitasking.

In cooperative the OS hands control to a process/thread and then waits for control to be handed back. In pre-emptive, control is handed over but the OS will grab control back when it wants. It will want control back after various interrupts, when the process asks for the OS to do something, or at the end of your time slice.

All of the issues that I discussed in Threads vs Forking (Java vs Perl) simply do not exist for cooperative multitasking. There is never any problem with unexpected interruptions because nobody is going to interrupt you. But on the flip side any process can lock up the whole system permanently. Furthermore pre-emptive both can accomplish background tasks faster and is more responsive. (Ironically, throughput on batch jobs can be higher in cooperative - there is no need to worry about locking and unlocking.)

MacOS is cooperative. DOS was. Ditto Windows 3.1. Microsoft claims that the Win9x line is pre-emptive, but in truth it is a hybrid, cooperatively multitasking 16-bit programs and pre-emptively multitasking 32-bit ones. (This was probably wise, if you pre-emptively multitask a process that was written for cooperative multitasking, a lot of race conditions come out of the woodwork.)

By comparison Windows NT, BeOS, any form of *nix, VMS and so on are all pre-emptively multitasked. Indeed so is OS X. Virtually anything billed as heavy-duty, certainly anything that can use 2 CPUs, have multiple users at once, etc are pre-emptive.

What this means is that on the Mac a single poorly-written process can lock up the system. Similarly if you go to the menu bar, while you are viewing the menu nothing else is going on. Your webserver is unavailable, your print jobs are not spooling, and SETI is going on without you...

This is true for virtually no other OS you are likely to encounter today.

MacOS is cooperative.[....]

By comparison Windows NT [is] pre-emptively multitasked.[....]

What this means is that on the Mac a single poorly-written process can lock up the system.

Note that a single program that isn't even very poorly written can quite effectively lock up Windows NT. All you need is something that takes up a lot of CPU. Designing a complex program such that it will never use "too much CPU" is extremely difficult. This is a problem that is best solved by the pre-emptively multitasking operating system. Unfortunately, WindowsNT "solves" this problem so badly that it really isn't solved at all.

Once a CPU hog starts running, WindowsNT manages to let other things run but at such a slow pace that it can takes hours to simply request that the system be shut down. Finding and stopping the hog is unthinkable. Anything not via the desktop is useless because response is so slow that time-outs are all that can be had.

So one badly written process probably can't completely lock up NT as far as scheduling is concerned, but the scheduling is not good enough for this to have much pracitcal meaning.

And now, back to discussions remotely related to Perl... :)

        - tye (but my friends call me "Tye")

Now let's be fair. Save the following and run it on virtually any *nix system:

#! /bin/sh
# Tie up memory
perl -e 'push @big, 1 while 1'
# Breed
sh $0 &
# And be a real hog
while [ true ]
do
    $0
    sleep 1
done
[download]

I am pretty sure I have it right.

If I do, run it and unless ulimits have not been properly set you will see hogging in action!

Don't worry about taking hours to request that the system be properly shut down. You will need to do a hard reboot.

My experience is that NT has awful performance on switching processes. I believe that Linux switches processes faster than NT switches threads. However NT in my experience survives casual CPU and memory starvation much better than Linux does. Try a few test Perl scripts out and see if you don't find the same.

OTOH I have seen occasional badly behaved processes (Lotus Notes on a couple of systems comes to mind) which reduce NT to sheer misery. For instance there is some kind of locking conflict which leaves NT at 1% CPU usage.

In general denial of service is a hard problem to solve. NT has worse average behaviour but tries to handle some DoS situations. Linux has better average behaviour but does not even try to think about DoS. It is far too easy to get either into really sad obscure failure modes.

But hey, if reliability is your top concern, why aren't you running an AS 400?