Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!wang!bu-tyng!three!cory
From: cory@three.MV.COM (Cory Kempf)
Newsgroups: comp.arch
Subject: Re^2: Macintosh OS
Message-ID: <355@three.MV.COM>
Date: 6 Jun 90 01:52:15 GMT
References: <402@newave.UUCP> <3300131@m.cs.uiuc.edu> <5031@quanta.eng.ohio-state.edu> <1990May28.083518.26003@laguna.ccsf.caltech.edu> <54992@microsoft.UUCP> <12189@cbmvax.commodore.com>
Organization: Three Letter Co. Nashua, NH.
Lines: 32

jesup@cbmvax.commodore.com (Randell Jesup) writes:

>In article <54992@microsoft.UUCP> edwardj@microsoft.UUCP (Edward JUNG) writes:
>>The thing that pre-emptive multitasking does is give guarantees against poor
>>code. 

>	Note that in this case, "poor code" can mean anything that runs for
>a signifigant period without explicitly giving up the processor.  This includes
>most "standard" C programs which use appreciable processor time, such as
>ray tracers.  

A properly written user oriented program would check for events frequently, 
even in the middle of a heavy duty CPU burst.  That is just good user 
oriented development though.  Remember: The USER is in control.

>		It also means that background tasks doing IO may not work well
>or at all if the frontmost application doesn't give up the cpu VERY often,
>since various buffers may overflow, etc.

See above.  At a minimum, each application should get some CPU time each
second.  If your application is processing in bursts that are too large,
it is broken -- it needs to be fixed.

One side note: Mac System 7 gives the user the ability to interupt and 
terminate any job that is taking up too much CPU time  (at least that is 
what the docs say... I have yet to see it).

+C
-- 
Cory Kempf				I do speak for the company (sometimes).
Three Letter Company						603 883 2474
email: cory@three.mv.com, harvard!zinn!three!cory