🚀 go-pugleaf

nevin@CS.Arizona.EDU (Nevin ":-]" Liber) writes:

>In article <19960204.10AE3B8.A1B8@olympus.net>, dons@olympus.net (Don
>Schmelling) wrote:
>
>> I never said that you could not break out of this program.
>> I was attempting to say, that while this program is running
>> you are not multitasking.
>
>Well, I obviously am on some level, since the mechanism that allows me to
>break out of this program is not part of the infinite loop itself.  The
>clock on my menu bar updates also.  Now, my system may not automatically
>go to another high-level process, but it certainly allows other
>lower-level tasks to continue executing.

By using this great argumentation, CP/M-80, MSDOS, as well as all the
"operating systems" of the 8-bit micros (ZX-81, Spectrum, C64, etc) can be
qualified as "multitasking", because all of them were using interrupts.

>Of course it is the issue.  Programming is a contract between the
>programmer and the OS.  If the programmer breaks the rules, bad things
>happen.  I have yet to use a system that has absolutely no rules at all.

For many applications, programming is a contract between the programmer
and the programming language used.  The for(;;); example doesn't break this
contract, it's a perfectly portable program.  It runs very well in
multitasking systems (Unix, VMS, VM/CMS, etc), it monopolizes the cpu
resources of non-multitasking systems (MSDOS, MacOS).
>
>> The issue is that a badly written program
>> can hog the cpu on a CMT system while on a PMT system the program is
>> given a certain amount of cpu.
>
>That is because one of the rules of programming a CMT system is that you
>have to give up time for other processes to run.  Duh.  Are you really,
>truly, honestly so dumb that you don't understand this?  If you really
>don't, then you are too stupid to be programming a Mac or Windows or DOS
>machine.

You're too stupid to understand that portable programs shouldn't care
about the underlying operating system.  Once you start stuffing your code
with OS-specific calls, it is NOT portable any longer.

How often are the famous Byte benchmarks giving up time for other processes
to run?

Dan
-- 
Dan Pop
CERN, CN Division
Email: danpop@mail.cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland