Xref: utzoo comp.sys.mac:14174 comp.windows.misc:332
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!hplabs!decwrl!labrea!polya!ali
From: ali@polya.STANFORD.EDU (Ali Ozer)
Newsgroups: comp.sys.mac,comp.windows.misc
Subject: Re: Multifinder - why I *don't* want real multitasking?
Message-ID: <2159@polya.STANFORD.EDU>
Date: 19 Mar 88 03:50:14 GMT
References: <3268@zeus.TEK.COM> <1092@its63b.ed.ac.uk>
Reply-To: ali@polya.UUCP (Ali Ozer)
Organization: Stanford University
Lines: 22
Keywords: Mac, Multifinder, Multitasking

In article <1092@its63b.ed.ac.uk> nick%ed.lfcs@uk.ac.ucl.cs.nss writes:
>   If I'm running some sort of package which does real-time things,
>like timing events, and doing things at certain times, I presumably
>don't want the OS occasionally kicking in to attempt a re-scheduling,
>even if nothing else is runnable. At least with Multifinder's
>approach, if my time-critical application has the machine, it keeps it
>until it's finished.

On a single-user machine, you should have a means with which you can
stop multitasking. As Matt mentioned in an earlier message, the Amiga
for instance, provides the Forbid()/Permit() pair (which simply tells
the scheduler not to schedule another task) and the Disable()/Enable()
pair (which prevents the scheduler from kicking in at all). These are
implemented very efficiently, are nestable, and they will be suspended
(temporarily) if your task happens to call Wait() or somehow falls
asleep (otherwise what do you get?! 8-).

Of course you normally wouldn't use these (even if you were operating at
MIDI speeds), but sometimes it's a good idea (for instance, if you are
examining the system list of tasks, and don't want it to change and leave
you with a dangling pointer!).

Ali Ozer, ali@polya.stanford.edu