From: ewright@convex.com (Edward V. Wright)
Subject: Re: the NeXT option (Was Re: 7.1 vs. OS/2 and Windows NT)
Date: Thu, 15 Oct 1992 17:15:34 GMT
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

In <zh2znf-@rpi.edu> johnsd2@vccnw05.its.rpi.edu (Daniel Norman Johnson) writes:

>|> Sigh.  How many times must I repeat myself?  In the general case,
>|> that will simply not work. No matter how high you set an application's
>|> priority, it's still possible for it to starve if you have enough
>|> competing processes.  Raising the priority just raises the definition
>|> of "enough," it doesn't solve the basic problem.

>Well, if your priority is a signed integer, how bout 0x7FFF?

Fails as soon as another program sets its priority to 0x7FFF.


>In that case, you could use Forbid() and Permit() type
>operations, and turn of the multitasking. But this isnt
>something Id like to do just for painting. (which doens't
>require 100 MHz, I hope)

That depends on how complex the operation is.  I guarantee,
I can design a paint tool that will require 100 MHz and then
some.  Real-time convolution kernals, for example.


>|> >The definition I use for co-operative multitasking is a technique for
>|> >multitasking where a process can only be switched out if it executes
>|> >a call that does this. (such as, say, WaitNextEvent :) ); 
>|> 
>|> Or Permit?

>No. Permit() does NOT switch the task out; it sez "ok OS, you can
>switch me out now if you want!"

Same with WaitNextEvent.  It doesn't switch the task out, it just
tells the OS that it's okay to do so if another task is waiting.


>|> System 7 already does this.  It's called "Force Quit."

>I didn't mean when the user pushes <command>-<shift>-<esc>; I mean
>ANY key. So you can type into a word processor, say. Also pre-empting
>for mousedowns, mouse movements (macintosh style mouse-moved
>events, that is, not just any old motion), and so on.

Hm?  I'm not sure what you mean by this.  I'm sure you wouldn't want
to "force quit" a background application everytime you press a key.
As for the other things, the macintosh already does them just fine
now, so I don't see the advantage in changing.


>|> One call.  One line of code.  That's what it takes to make a
>|> typical Macintosh application multitask.  Actually, not even
>|> that, since that same call is necessary anyway to do other
>|> things.  

>It isn't THAT difficult, if you set up a procedure that
>calls WaitNextEvent and handles a few events (update, activates,
>OSEvents and Apple Events basically; perhaps keydowns so
>command-. will work also); You need to call this procedure
>in all your loops (ie more than once);

All Macintosh applications have such a procedure anyway.  You
can't write a Macintosh-style application without one.

>Of course, this assumes NO user interface, which is naughty.
>You'd also want to put up a movable modal dialog with some text
>and a thermometer. This isn't hard, not even as hard as Apple seems
>to think it is, but its more than 1 line of code.

I never said a Macintosh application could be written in 1 line
of code.  I said that 1 line of code is all that's necessary to
do the cooperative multitasking. 

>|> Now, in a 10,000-line program, that call represents .01% of
>|> the code.  Yes, it might be easier if you didn't need it.
>|> But *significantly* easier?  Good lord, you might as well
>|> complain that C programming would be easier if you didn't
>|> need to type the name of the function "main."

>Yes, significantly easier. Getting this WNE stuff to work requires
>tweaking- you have to make sure it gets called enough,
>but not too much. 

I've written dozens of Macintosh programs and never had to do
any "tweaking" to make them multitask.  I don't know who you've
been talking to about this, but I think he's been pulling your
leg.
 
















Newsgroups: comp.sys.mac.advocacy