Prevent fork bomb

[Aeneas]

+1 for DOS, too! It is actually an extremely cool OS.

Hey, it gets even more fine-grained, if you like... If I recall correctly, RSX-11(M at least) allows you to specify WHERE in memory your task shall run. Like, the memory area.

It is just that an average Windows user is faaar from such finicky considerations. I mean, does your aunt enforce process count limitations?

And as to the priority right now, it is as if you discuss the reliefs of the Domus Aurea while living in a straw hut...

[dizt3mp3r]

RSX = Irish sex, on the ICL VME o/s you would specify exactly where on disc you wanted to place your files for optimal access. It is still done today when you want to optimise a disc array, only using a very small portion of each disc causes file placement on the fastest tracks. Not explicitly stated but still functionally achievable.

I always believe that simple quotas should exist and then the operating system should maintain them and work within them, it is well within their capability. The fact that Windows does not have such quotas is not necessarily a good thing, if you believe that Windows always does everything right then there will be no convincing you one way or another.

[Aeneas]

(BTW: Maybe I was not clear above - Linux' limits.conf-file and BSD's mechanism (loader.conf in FreeBSD?) DO "defend against fork bombs" as a side effect. - I believe in Mac OS X it is even enabled by default. If you set a process count limit and then "fork bomb", at some point simply no new processes are spawned. Whatever the load is that the system then has, that's it - nothing more is taken and it does not crash.)

[middings]

Raymond Chen discusses the general problem in his blog article It rather involved being on the other side of this airtight hatchway: Denial of service by high CPU usage.

My understanding* is that the processes running at a given priority level share the CPU time available to that priority level. Adding more processes only divides the time available to all processes at that priority into smaller pieces. Time is not robbed from higher priority processes. The OS kernel runs at a very high priority so if a process slows the machine unacceptably then the user can stop it. If a virus can start a fork bomb at the same priority level as the OS, then the machine is already compromised.

*usually wrong or oversimplified.

[erkinalp]

It has to have more permission than kernel to be able to be started at kernel realtime level

the processes running at a given priority level share the CPU time available to that priority level

Swapping out the part of scheduler responsible of calculating timeslice lenghts will solve that(A lot of commercial Unixes did that).