Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!rex!ukma!usenet.ins.cwru.edu!ncoast!davewt
From: davewt@NCoast.ORG (David Wright)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: How do we change the scheduler? (Was Re: Multitasking at home...)
Message-ID: <1991Jan24.152931.1325@NCoast.ORG>
Date: 24 Jan 91 15:29:31 GMT
References: <10620.tnews@templar.actrix.gen.nz> <1991Jan22.215801.4557@Neon.Stanfor <1991Jan23.213736.28220@Neon.Stanford.EDU>
Organization: North Coast Computer Resources (ncoast)
Lines: 62

In article <1991Jan23.213736.28220@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes:
>jbickers@templar.actrix.gen.nz (John Bickers) writes:
>
>  Do user actions include "mouse-downs" in things like scroll-bars etc??
	Yes, as well as mouse movements, keys such as the shift key being
pressed and released, disks being inserted and removed, virtually everything.
>  How does a program become an input handler?  I presume you can spawn
>off a task, and tell it to be an input handler...   
	It depends on what you want to do. If you want to ONLY be an
input handler you should be a very small and fast program, and you can
put yourself into the input even chain above or below the mian system
input handler. But this is nor usually reccomended. The better way to do
this is to write an application that follows the guildelines for running
under "Commodities Exchange", which is available under 2.0. This lets you
write an input event handler that can take out or insert events into the
input even queue and still get along with other programs doing the same
thing. And the user gets a nice WorkBench control panel that lets them
freeze, restart, and remove any CEX applications they wish.
>  I'm mainly interested in the 2nd level, i.e. how a normal
>application would handle getting and processing events in an
>interactive fashion.  
>  You say some programs do use input-handlers... does this mean they
>multi-thread themselves, spinning off an input handler task, and then
>communicate between the main program and the input handler task?
	If they wish, but that is not normally needed. Most programs on
any machine are waiting for user input, not running in the background.
For instance a paint program would have no need to spawn another task
for input, since it is always waiting. And under Intuition, the task doesn't
even have to be ready for input for you to click in it's gadgets or select
pull-down menus. The program will get the events from it's private input
queue when it is ready for them.
>task.  If the word processor task remains at priority 1, this code
>won't get run until the WP's task gets scheduled by the scheduler
>(which on a heavily loaded system may be in the tenths of a second).
>  Thus, it seems to be possible to buffer up a whole lot of mousedowns
>on the scroll bar, all received by the input.device task, but the
>actual code to regenerate the window won't be scheduled...  thus won't
>you get a jerky, or at least a non-responsive task?
	Yes, but the user would expect this, if they had a lot of other
programs running at the same priority.
>  I'm just wondering if you would get better response by having the OS
>temporarily boosting the priority of an interactive task (e.g. raising
>the word processor priority to 10 while the user is clicking on the
>scroll bar in the WP's window)
	Yes, this would work. But is very rude, and not many programs do
this. How do you know that the user WANTS the WP to work smoothly?
Personally, I run a multi-user game on my computer 100% of the time, in
the background. I want the remote users I/O to be as fast as possible, so
I run their programs at a higher priority (2 & 3), while I run mine at
0 or less. I would refuse to use a WP that upped it's priority without
asking my permission. I expect the repsonse to be slower (although
normally neither myself and the other users can't tell anyone is using
the system besides themselves), and I'm willing to live with it, those
rare times it occurs. But technically, yes, you could do what you
want. But why not just run at the same priority all the time? If the
user wants faster response they can up the WP priority. Since most of the
time it will be waiting for user input, the other tasks will get plenty
of time to run in the background, even if the user has the WP running at
a high priority.


				Dave