Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!agate!shelby!polya!gilham
From: gilham@polya.Stanford.EDU (Fred Gilham)
Newsgroups: comp.sys.amiga
Subject: Re: Apple System 7.0 [ and some 1.4 suggestions ]
Message-ID: <9160@polya.Stanford.EDU>
Date: 13 May 89 16:07:03 GMT
References: <17148@usc.edu> <24279@agate.BERKELEY.EDU> <18268@cup.portal.com> <17183@usc.edu> <21814@srcsip.UUCP> <5847@cs.Buffalo.EDU>
Sender: Fred Gilham <gilham@polya.Stanford.EDU>
Reply-To: gilham@polya.Stanford.EDU (Fred Gilham)
Organization: Stanford University
Lines: 20

In article <5847@cs.Buffalo.EDU> ugkamins@sunybcs.UUCP (John Kaminski) writes:
>
>   One blemish of the Amiga is
>that it provides Enable(), Disable(), Permit(), and Forbid().  Any process
>utilizing these falls into the same class as Multifinder.  R U listening,
>CATS guys?  Provide access functions to the programs that do this, to do
>what those programs do, which is generally access to system structures any-
>way.
>

I used Forbid() and Permit() to allow me to start up a task where
things weren't quite ready for it.  The parent simply did a Forbid()
until it had finished setting things up.  This seemed like a good use
of Forbid() to me.

Admittedly it is possible to get carried away.  However, it is much
easier to not do something than to do it.  Having to give up the
processor by hand seems kludgy to me.  Being able to hang on to it if
you REALLY need it seems flexible.  You don't HAVE to use Forbid().
-Fred Gilham