🚀 go-pugleaf

In article <kjfair-0602962055530001@ngrh-34.rh.uchicago.edu>,
Kenneth Jason Fair <kjfair@midway.uchicago.edu> wrote:
>In article <kevinbDMCMIy.B26@netcom.com>, kevin@frobozz.sccsi.com (Kevin
>Brown) wrote:
>
>>In article <nevin-0302960411460001@150.135.1.79>,
>>Nevin ":-]" Liber <nevin@CS.Arizona.EDU> wrote:
>>>If I ever have an occasion to run a brain-dead program like void
>>>main(void) { for (;;); }, I'll let you know.  It isn't a very interesting
>>>question to me, since it just doesn't come up in Real Life.  If you wish
>>>to pay me to test brain dead programs on a Mac, I'd be more than happy to
>>>oblige.
>>
>>Fine.  Then try running a "brain-dead" program like this instead:
>>
>>        main()
>>        {
>>            while ( there_is_useful_work_to_be_done )
>>            {
>>                do_the_computationally_intensive_useful_work();
>>            }
>>            display_the_results();
>>        }
>>
>>where there_is_useful_work_to_be_done remains true for long periods of
>>time (minutes, hours, perhaps even days).
>>
>>Such a program could be an image renderer (e.g., the type used to
>>produce "Toy Story") or a finite element analysis program, or any
>>number of useful things.
>
>And this is, in fact, how the typical Mac program operates.  In general:
>
>main()
>{
>   InitOSStuff();
>   InitYourProgram();
>
>   while ( there_is_useful_work_to_be_done )
>   {
>      WaitNextEvent(parms);
>      switch (event)
>/*  handle the various types of events, keypresses, etc.  */
>         do_the_computationally_intensive_work();
>   }
>   CleanUpProgram():
>}
>
>
>Again, the only real difference is that you should throw a WaitNextEvent
>in so that your program checks to see if the user has called for a context
>switch.  You don't have to make your program recognize any events. You can 
>even make your program background only if you want.  This takes ten minutes
>to figure out.  It's probably one of the three or four things I learned
>first about programming the Mac.  And I'm not even a good programmer.

Can a "background" program also do user interface stuff, or must it
merely be an invisible daemon?  Can a "background" program switch
itself into the foreground when it needs to?

What if do_the_computationally_intensive_work() can take an arbitrary
and unpredictable amount of time to execute?

>Cooperative multitasking IS still multitasking, even with rogue programs
>that won't release the CPU.  They're just not COOPERATING.  That's why
>it's called *cooperative* multitasking.  

Right.  But what's the difference between saying that a program isn't
"cooperating" and that it has disabled multitasking (i.e., when the
system is executing the rogue program, it's no longer multitasking)?
Looks like the same thing to me...

>True, PM doesn't require cooperation
>on the part of the programs.  Yes, that does make things a bit more
>flexible.  But it's just not a big problem 99.9% of the time.

It's not a big problem because most people don't run
computationally-intensive programs.  They run word processors,
spreadsheets, games, and the like, most of which are I/O intensive.
Whether this state of affairs is because that's the type of thing most
people *want* to do, or if it's because the most popular systems
haven't really been capable of much more, is difficult to say
(it's possibly some combination of both).

>          ** Fuck the Communications Decency Act of 1996. **

I completely agree.


-- 
Kevin Brown                                     kevin@frobozz.sccsi.com
This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end >
            This is your .signature virus on drugs: <>
                        Any questions?