🚀 go-pugleaf

From: Brad Miller <miller@CS.ROCHESTER.EDU>

    Date: 15 Dec 88 20:18:09 GMT
    From: goldman@Apple.COM (Phil Goldman)

    In article <1988Dec14.223739.16280@cs.rochester.edu> @DOUGHNUT.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU writes:
    >It's something of a pity multifinder doesn't already do this; one could have
    >a reasonable yet small IPC standard based on pointers to heap objects... and
    >then consumers of a stream could run simultaneously with the producer,
    >rather than the current braindamage of producing a file, switching to the
    >next program, reading the file...

    This has nothing to do with whether the multitasking is preemptive or not.
    In fact, doing producer/consumer on shared memory *is* possible with
    MultiFinder.  It is absolutely not necessary to do IPC thru files.

Correct; I was inferring something about the implementation from the current
behavior of multifinder, which was apparently a bad thing to do. (I also did
not mean to imply that "preemptive mutitasking" isn't possible on the 68000;
you simply cannot interrupt in the middle of an instruction the way a page
fault might. One can certainly cause a task switch between arbitrary
instructions. In fact there is no reason the 68000 can't also support memory
management on a more primitive level than demand paging, e.g. swapping.
Since I suspect most owners of SE class or better machines (and probably a
lot of Plus owners as well: I have 90megs) have a hard disk, swapping may
well be a feasible and desirable next step for system development.)

I discuss true multitasking further below.

    It is true that Apple is not yet officially supporting a full-blown
    IPC mechanism, but there are numerous ways to do it already anyway.

Umm, yes, if the interface for multitasking were better... How do I, for
instance, set up a new type of event, and *sleep* until it occurs?
(additionally, some other process will post the event...) Sure, I can set up
a monitor and have each process run the monitor to check if the event has
occured, but this is a major waste of cycles. I shouldn't get scheduled
unless I have something to do.

    As an aside to the person asking about TRUE multitasking in 8.0, MultiFinder
    already supports true multitasking.  That is, it divvies up CPU time
    between multiple applications.  If the reference is to preemptive multitasking,
    then there is really no reason to get excited.  Preemptive multitasking
    will make life a bit easier on developers, but not much, and have no
    typical effect on users.  The only point at which preemptive multitasking is
    more useful to a Mac end user is when he is using a buggy app.

    -Phil Goldman
    Apple Computer

Preemptive multitasking, if I understand what you are referring to, is a big
win for everyone because (for one) it means applications developed for
pre-multifinder macintoshs (or applications that aren't written specifically
with multitasking in mind) will happly coexist with multifinder
applications. That is, since they will get switched out whether they request
it or not, the system will seem a lot more reponsive.  Further, given a
reasonable scheduler, the user can set priorities, etc.  allowing compute
intesive tasks to run at a lower priority than highly interactive tasks.
(the system can also do this automatically with some idea of quantums). 

We both agree that it is a big win for developers too, though I think to be
useful it has some implications for the UI. The main thing is that the
developer shouldn't have to worry about making his process multitaskable,
and right now he does.

I have some difficulty understanding the claim that multifinder already
supports true multitasking:

 o As far as I can tell there is no way to put a process to sleep until some
   event happens. Further, since most processes are already written to use
   non-waiting i/o it isn't easy to just change the non-waiting i/o calls to
   waiting i/o calls. Yet clearly code of the form

	(let ((event (get-event MASK)))
	   (loop (if event
		     (proccess-event event)
		     (let-das-run)) ; really allow-procees-switch anymore...
		 (setq event (get-event MASK))))

or it's equivalent in your favorite language is very inefficient; tasks must
be switched to to do nothing more than find out they have no event to
process. two task switches (at least) are wasted in this fashon.

 o Further, synchronous i/o, like to the disk, do not seem to enable a task
switch; at least by experimentation under release 6.0 I could not get
multifinder to switch tasks while finder was copying a file, or even while
an application was reading a file. While I can understand (though still
consider faulty) why certain systems, e.g. lisp machines, do not allow a
reschedule during a page fault, there isn't any excuse not to task switch
during disk i/o. Disks are slow. Processes are fast. 

This may be a side effect of mouse/keyboard handling; unless your mouse and
or keyboard is controlled by a separate process, a lot of the nice side
effects of multitasking are wasted; I can't conveniently switch forground
tasks or queue information for multiple tasks at one time. (since mouse
movement occured during the disk activity, I presume only clicks were being
ignored?)

 o I've also noticed that tasks that put up dialog boxes also inhibit my
switching tasks from multifinder. Lose, lose. This may be a side effect of
the first point; that the application writer doesn't explicitly allow a task
switch while asking for input from the dialog box, but on the other hand,
making processes interruptible isn't a task for the application writer but
for the OS to do, it seems to me. Yet another reason for "preemptive
multitasking" to be supported, then.

Now this does not mean that there isn't low level support for multitasking,
just that given the above points, it's well hidden from the user. As far as
I can tell, I have a foreground process, and my background processes wait
until I'm doing i/o when I can switch to them.

At any rate, while I have years of experience hacking OS kernels, my mac
experience is limited to about a month now. I'd love to be corrected on any
misunderstandings in my assumptions above.

----
Brad Miller		U. Rochester Comp Sci Dept.
miller@cs.rochester.edu {...allegra!rochester!miller}