Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!mips!sgi!shinobu!odin!aldur!mattly
From: mattly@aldur.sgi.com (James Mattly)
Newsgroups: comp.arch
Subject: Re: Macintosh OS
Message-ID: <8767@odin.corp.sgi.com>
Date: 8 Jun 90 21:54:26 GMT
References: <1990Jun7.212351.20426@calgary.uucp>
Sender: news@odin.corp.sgi.com
Reply-To: mattly@aldur.sgi.com (James Mattly)
Followup-To: re: Macintosh OS
Organization: Silicon Graphics, Entry Systems Division
Lines: 70

In article <1990Jun7.212351.20426@calgary.uucp>,
deraadt@enme.UCalgary.CA (Theo Deraadt) writes:
> In article <1990Jun6.222126.2888@midway.uchicago.edu>,
gft_robert@gsbacd.uchicago.edu writes
> >In article <:SY35CD@xds13.ferranti.com>, peter@ficc.ferranti.com
(Peter da Silva) writes...
> >>How about the fact that programmers may have better things to do with their
> >>time than warp code to fit into the windowing universe? I realise that on
> >>the mac 90% of the programs are 90% user-interface, but that's not always
> >>the best way to do things. A compiler, for example, really has no business
> >>calling GetNextEvent *ever*.
> >
> >And if the user wants to interrupt the compilation mid-compile? 
You'd better
> >have some way of finding at least this out.  GetNextEvent (or WaitNextEvent)
> >seems the proper way to do this to me.
> >
> >You may indeed have to change some of your code to run properly on the Mac.
> >Or put another way: you may have to change some of your code to put the user
> >incomplete control.  The above example as a case in point.
> 
> And why are signals (esp. unix type signals) not a correct way to
handle this?
> Calling GetNextEvent() sounds like polling to me.
> 
> So, if I wanted to do a large matrix add, I would have to call GetNextEvent()
> every couple of rows perhaps. And where do I put GetNextEvent() in my
> compiler? I guess I put it in the parser, and it calls GetNextEvent() every
> 100th token or something like that. For heavily recursive stuff, does this
> not seem to get overly messy?
>  <tdr.
> 
Exactly!
	Why should the programmer belly-ache about putting the GetNextEvent()
into their program when the compiler could do a simmilar job.  Consider using
the pragma() directive in C compilers, (or {$switch+/-} for pascal), to turn
on or off an automatic placement of GetNextEvent, or some equivalent call after
every n lines of code.  Or inside a loop (not a time critical one!).  Or 
inside the basic blocks (for all those compiler fans out there!).  This
would seem to release the programmer from putting a GetNextEvent every so often
(which seems to be the basis of everyones complaint) and still gain the
benefits
from calling it.

	This approach wins for the programmer who doesn't want to "break" his
train of thought while writing a peice of code.  It also wins for the Mac OS
which lets the programmer decide when a context switch would be a good idea
(IMHO, the best reason for Cooperative Multitasking).

	Perhaps Apple could set up a variant of GetNextEvent (or WaitNextEvent),
which is optimized for this specific use.  Also perhaps the compiler could have
options to specify the parameters which are used for the automatic calls. There
should probobly be a function which is called if the GetNextEvent notices a 
UpdateEvt, or a Command-. combination, again configurable through pragma's so
that the response function could be changed in different sections of code.

	Personaly I prefer the idea of "Cooperative" Multitasking (although I
would like to have seperate address spaces) because it eliminates many hangups
for OS designers to worry about. (If the application developer can't
write code,
he shouldn't be programming :-) Preemptive Multitasking seems to rape processes
if they don't behave.  Preemptive Multitasking was 'designed' when I/O was a
good thing for the scheduler.

	Any way seemed like a good idea when I typed it up, enjoy.

--------------------
	James Mattly (mattly@aldur.esd.sgi.com)
	You actualy think that SGI listens to me?  Wow what a concept!
----------------