From: johnsd2@vccsouth15.its.rpi.edu (Daniel Norman Johnson)
Subject: Re: the NeXT option (Was Re: 7.1 vs. OS/2 and Windows NT)
Reply-To: johnsd2@rpi.edu
Organization: Rensselaer Polytechnic Institute, Troy, NY.
Date: Thu, 15 Oct 1992 20:08:06 GMT

In article <ewright.719169334@convex.convex.com>, ewright@convex.com (Edward V. Wright) writes:
|> 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.

Hmm, yerright. But it would work for paint tools anyway (unless
you can think of a way to use 2 paint tools in 2 apps at the
same time) It would not work for other things that COULD
have 2 apps doing them at the same time, both requiring
uninterruptability. So on to Forbid()...

|> 
|> >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.

Ow. Well, if its more than your processor can handle with ALL the CPU
time, no multitasking trick will help, and the point becomes exceedingly
moot. However, if we stick to things that your computer can actually
DO... :)

|> 
|> >|> >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.

This is NOT the same as WaitNextEvent. WaitNextEvent actually
SWITCHES you out, right then and there (or else it doesn't, as you
pointed out); Permit() tells the OS that it may do so at any time
it likes. The switch does NOT happen within the Permit() (I dont
think); at least Permit() could be done so that it didn't switch
out, under any circumstances. (but you might be switched out a microsecond
later of the OS felt like it)

The MacOS will NEVER switch out a task on its own.
(well, ok, there are some interrupts that can do this,
but you can't do anything interactive with them, because
of the memory-movement thing)

|> 
|> >|> 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.

We are definitely talking on different wavelengths here. I dont
mean pressing a key should stop the processing of the app it interrupts;
that app should only be switched out so that the keydown event can be
sent to the appropriate app. (or the mousedown, or whatever)

The interrupted app would get switched back in, normally. Later.

As for the other things, well I can't interrupt my spell-checker and
do something else while it is working...

|> 
|> >|> 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.

Yes you can. You do not have to differentiate updates+activates
from keydowns+mousedowns (and so on); they could all be done
in one big handler, or just a case somewhere. This would
not work for the background stuffs because although the updates+
activates would go thru fine, keydowns and mousedowns must be
handled differently. (for instance, detecting command-.s);

Its better if you DO separate them so, but then ts also better
if you switch out at the appropriate time. Separating them
requires you write more code (at least a procedure declarating
and call)

|> >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. 

No, nonono!!!!! That is not at ALL what I am saying! This is
getting very irksome. Pardon me... <fume fume>

Ok, I mean a user interface for the MULTITASKING. The thermometer-
the watch cursor.. you know... that stuff...

Naturally, you would also want to write the rest of the app, too.

In any case, it takes more than one line of code to do this.
You need to do this in each loop, and if you have more than one
loop, that's more than one line of code. Each loop could
have 1 line of code, but that assumes you have a procedure somehwere
else to do it. This procedure must call waitnextevent, then
handle the event. More than one line of code, certainly.

(well, ok, you could write it all on one line, but then it would
be unreadable, and very wide to boot)

|> >|> 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.
|>  

I didn't "talk" to ANYONE. This is my ->own<- experience. I ->do<-
have to tweek it to get decent multitasking. If you know a way
around this, tell me! (please) It would make my programming easier
if I didn't have to tweek sleep values, etc.

-- 
			- Dan Johnson
And God said "Jeeze, this is dull"... and it *WAS* dull. Genesis 0:0

These opinions have had all identifiying marks removed, and are untraceable.
You'll never know whose they are.
Newsgroups: comp.sys.mac.advocacy