Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!bagate!cbmvax!peter
From: peter@cbmvax.commodore.com (Peter Cherna)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Scheduler changed under 2.0?
Message-ID: <15887@cbmvax.commodore.com>
Date: 15 Nov 90 15:42:44 GMT
References: <90312.082534GIAMPAL@auvm.auvm.edu> <15756@cbmvax.commodore.com> <90316.091455GIAMPAL@auvm.auvm.edu> <1834c248.ARN04024@adspdk.UUCP>
Reply-To: peter@cbmvax.commodore.com (Peter Cherna)
Organization: Commodore, West Chester, PA
Lines: 57

In article <1834c248.ARN04024@adspdk.UUCP> hclausen@adspdk.UUCP writes:
>   I've found that Intuition under 2.0 seems to execute the OpenWindow()
>etc. etc. calls with the priority of the caller. If some task is eating
>away practically all CPU time at a higher priority, the mouse pointer and
>everything else will hang, though the system is certainly alive. I
>encounter this mostly when uniconifying my text editor while doing compiles
>- the OpenScreen() & OpenWindow() calls hang until the compiler accesses
>the disk, thus freeing up some CPU time. This was different under 1.3.

Parts of Intuition run on the caller's task, but much of the interesting
stuff runs on the input.device's task, which runs at priority 20.
Whenever you call a function, you do start out on your own task of course.
In OpenWindow(), for example, most of the checks and allocations happen
on your task (some of it must: the message ports for example, must
be created on your task, since they allocate signal bits from the
running task!).  But internally, Intuition is a bit like a device, so
OpenWindow() eventually sends a message, which input.device (running
as Intuition) picks up, and links your window in on its schedule.

Some Intuition calls happen entirely on your task, some happen nearly
entirely on input.device's task, and some are divided.  Some are synchronous,
and some aren't.  We arrange things as design and historical constraints
dictate.  We let you know this information when it is relevant.  (For example,
after calling ActivateWindow(), your window isn't active until and unless
you hear an ACTIVEWINDOW IDCMP message, because ActivateWindow() is
asynch.

Finally, all the stuff that's asynchronous to the clients of Intuition
(such as moving the mouse, rearranging layers, and some refresh) happens
on the input.device.

>   So, it seems to be Intuition rather than the sceduler that has this
>change. Anyway, Exec wasn't changed much from 1.3 to 2.0 - it did a good
>job under 1.3 already. Intuition, on the other hand, has had much recoding.

Although Intuition has undergone substantial changes in 2.0 (thanks jimm!),
the basic pattern of splitting the work between the caller and input.device
has been in Intuition all along.

Note also that the number of changes a module underwent wasn't strictly
determined by how good a job or how well it was written.  Support for
the 2024 and ECS Denise, for example, meant a lot of work for graphics and
Intuition.

>                                 Have a nice day         -Henrik

As Bryce mentioned earlier, the delays people have been experiencing
are caused by bus errors generated in hardware on the Amiga 3000.  The
nature of the 1.3 SuperKickstart setup on A3000's allows us to supress
these errors.  (Each hardware bus error imposes a 1/4 sec pause).

     Peter
--
     Peter Cherna, Software Engineer, Commodore-Amiga, Inc.
     {uunet|rutgers}!cbmvax!peter    peter@cbmvax.commodore.com
My opinions do not necessarily represent the opinions of my employer.
I have found a proof for Fermat's theorem, but there is no room in the .sig!