Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!ai-lab!geech.ai.mit.edu!rjc
From: rjc@geech.ai.mit.edu (Ray Cromwell)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: How do we change the scheduler? (Was Re: Multitasking at home...)
Message-ID: <12933@life.ai.mit.edu>
Date: 23 Jan 91 23:55:20 GMT
References: <10620.tnews@templar.actrix.gen.nz| <1991Jan22.215801.4557@ <1991Jan23.213736.28220@Neon.Stanford.EDU|
Sender: news@ai.mit.edu
Organization: None
Lines: 92


In article <1991Jan23.213736.28220@Neon.Stanford.EDU| torrie@cs.stanford.edu (Evan J Torrie) writes:
|jbickers@templar.actrix.gen.nz (John Bickers) writes:
|
|Quoted from <1991Jan22.215801.4557@Neon.Stanford.EDU| by torrie@cs.stanford.edu (Evan J Torrie):

|    Consider that there are two levels to input handling. One is handling
|    receipt of the users actions (buffering keystrokes, moving the mouse
|    pointer, resizing windows, swapping screens, etc). The other is the
|
|  Do user actions include "mouse-downs" in things like scroll-bars etc??

  Yep. 
|    application actually getting around to doing something with the input.
|
|  This is what I'm interested in.
|
|    This gets input from the user, and funnels each event through a
|    chain of input handlers. The program JDMouse is one such, which
|
|  How does a program become an input handler?  I presume you can spawn
|off a task, and tell it to be an input handler...   

  There are a bunch of ways. One of the easiest is to ask the 
input.device to "please install my routine into your handler chain."
I've never written an input handler (most people don't need to), but
thats how I remember it. 

|    The 2nd level can be handled in a variety of ways (some programs
|    do use input-handlers as well as normal mechanisms), and varies
|    from program to program.
|
|  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?

  Most Amiga programs use IDCMP. This stands for Intuition Direct 
Communications Message Port :-) IDCMP is a Message Port that receive
input events from intuition that can range from timer ticks,
mouse move events, button clicks, someone picking a menu, hitting a
key, selecting a gadget, sizing a window, etc. Lots of stuff. Even
inserting a disk.
  See below.

|  What is the "normal mechanism"?
|
|  The particular scenario I'm interested in is this... suppose we have
|a word processing application, with scroll bars, etc running at a
|normal priority (say 1 or so) on a heavily loaded system.  
|  When a user clicks on the scroll bar, the ideal is to respond as
|quickly as possible (i.e. the text/pictures in the word processor
|scroll down quickly).
|  From the discussion above, it seems that the input.device task will
|handle the mouse down immediately (because it's running at such a high
|priority).  But normally, the code to regenerate the window's view
|(what I call an Update event) is located in the main word processor
|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).
  This is what makes the Amiga so nice. In a typical application. A program
opens a window and Intuition creates an IDCMP port. The program will
then Wait(MyWindow-|UserPort-|mp_SigBit) for an input event to occur.
The application at this point falls asleep. When an input event occurs
intuition sends a message to the Window's IDCMP(UserPort), Exec's
scheduler says 'Hey, this task was asleep waiting for this event, lets
wake him up.' The Application wakes up and Replys to the Message, then
processes it.

|  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?
   Intuition is smart, the internal window generation code runs on
the input.device task instead of the user task (notice in the list
that was posted, the input.device was eating 30% of CPU time.). Also,
rendering is done IN PARALLEL with the blitter chip, nice isn't it?
The only way lots of input events get buffered up, is if the user task 
doesn't respond to the messages intuition sends to its IDCMP port, or the
system is SEVERLY bogged down. I have never encountered this except
when I foolishly ran a program which set its priority higher than the
input.device.

|  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)

  Not really, unless your are running a ray-tracer at a higher priority
than your WP, which is stupid.