Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!brutus.cs.uiuc.edu!apple!Apple.COM!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac
Subject: Re: Real Multifinder (was Re: Hey Apple Mac engineers, answer->Ma)
Message-ID: <3997@internal.Apple.COM>
Date: 31 Aug 89 18:17:48 GMT
Sender: usenet@Apple.COM
Distribution: usa
Organization: Objects-R-Us,  Apple Computer, Inc.
Lines: 56
References:<46100321@uxe.cso.uiuc.edu> <1989Aug15.001507.14552@sj.ate.slb.com> <24626@iuvax.cs.indiana.edu>

In article <24626@iuvax.cs.indiana.edu> truel@iuvax.cs.indiana.edu (Bob 
Truel) writes:
> done any applications (didn't used to have enough memory :), so can 
someone
> who is knowledgeable give a rough estimate as to the size of code that 
must
> be included in every program in order to make it multifinder friendly, 
and 
> the time it takes to produce this code (say for the first time, for a 
fairly
> competant programmer). 

It is possible to work under MultiFinder without writing any extra code, 
although by writing some MultiFinder-specific code you can make the system 
operate more smoothly.

For most applications, the number of lines would be on the order of 50, 
and the lines are pretty well standardized.  One needs to use 
WaitNextEvent (when available) and respond to suspend/resume events  
(export the private clipboard and deactivate your window).

At the next level of complexity you have programs that use a lot of 
temporary memory, which could then take advantage of the MultiFinder 
temporary memory calls.  

Or you have programs that want to do a lengthy calculation in the 
background.  In that case you need some code to process events while you 
are doing the calculation.  If you have structured your application 
appropriately, then it shouldn't be very many lines of code.  You do have 
to locate the appropriate places in your algorithms for checking for 
events, etc.

>Is this enough justification for apple to provide an inherently 
multiprocessing system?

Of course.  The issue is supporting the existing application base.  In the 
case of MultiFinder, the question was whether it was better for customers 
to provide non-preemptive task scheduling, which could accomodate existing 
applications, or to provide a system that supported premptive multitasking 
but that required most or all applications to be rewritten.  With 
MultiFinder, users get much of the benefits of multitasking, although it 
puts more burden on developers.

> It is time for the main event loop to be done away with.

I don't think the event loop is the issue.  An event loop is pretty 
essential for any kind of highly interactive application.  The way to make 
things easier for the programmer is to provide an application framework 
that implements the standard event loop once and for all, so programmers 
can concentrate on what they really want to implement.

Larry Rosenstein, Apple Computer, Inc.
Object Specialist

Internet: lsr@Apple.com   UUCP: {nsc, sun}!apple!lsr
AppleLink: Rosenstein1