From: johnsd2@vccnw05.its.rpi.edu (Daniel Norman Johnson)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: the NeXT option (Was Re: 7.1 vs. OS/2 and Windows NT)
Date: 14 Oct 92 23:56:20 GMT
Article-I.D.: rpi.zh2znf-
Reply-To: johnsd2@rpi.edu
Organization: Rensselaer Polytechnic Institute, Troy, NY.

In article <ewright.719104145@convex.convex.com>, ewright@convex.com (Edward V. Wright) writes:
|> In <x_2zcrp@rpi.edu> johnsd2@jec323.its.rpi.edu (Daniel Norman Johnson) writes:
|> 
|> >It seems to me like it would be better just to jack your priority
|> >way up, and have some sort of mouse-tracking arrangement so that
|> >the system will remember where teh mouse goes when you are switched out.
|> 
|> 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?

Or howbout some special case that sez "gimme lots of time, but let
drivers and such pre-empt me" or something like that.

|> >This way stuff like background downloads could still get time- the
|> >driver for the device would pre-empt your program when it had some
|> >data to pass on. Or something like that.
|> 
|> Okay, look, you've got a 100-MHz 68050, or whatever.  But there
|> you've also got an application that *needs* all 100 MHz for several
|> seconds at a time.  Well, maybe it can get by with 99.98 MHz, but
|> that's still not going to leave enough for your background process.
|> The only solution is to let the background process starve (i.e.,
|> don't start a download when you're going to be using this monster)
|> or use multiple processors.

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)

|> And before you tell me that no single application requires a 100
|> million cycles per second just to give efficient response, yes,
|> that's true -- today.  But as soon as someone builds a 100-MHz
|> 68050, someone else will write a program that uses every bit of
|> it.

I wouldn't say such a thing. I know full well that this is true.

|> >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!"

The OS does it in its own good time, which depends on teh priority
of the task, etc.

|> >Also, there are some cases where it's nice ot be able to pre-empt a
|> >task. Say a program is computing away in the background; it would be
|> >nice to have the system pre-empt that task whenver the user hits a key,
|> >presses a mouse button, whatever, rather than waiting for that task to
|> >yield time. 
|> 
|> 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.

|> >If the task yields often enough everything works fine. But
|> >it's a pain to arrage that. It would be easier not to have to. 
|> 
|> 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.  

Wrongo. To make the OS work propoerly you have HANDLE the
events that are coming through. Otherwise you have some
nasty problems. If you dont update your iwndows when an update
event comes through, you will just keep getting that event
until you service it, and NOONE will get ANY nullEvents. Yuck!

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);

Or did you mean you want programmers to unwind their code so that
it is execute it little bits, from the main event loop? That's REALLY
painfull. (tho it provides features similar to multithreading)

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.

|> 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. The OS does not take care of this (alas).
It also involves more code that you are saying, although for big
programs like that its not so bad; you write the event handler
(and thermometer, etc) code onces, and just call it a lot.

Its something like saying C programming would be easier if it
had reference parameters. You can live with out them, and its not
that big a deal to use pointers, but don't you wish it just had
the blasted feature?
-- 
			- 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.