Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!agate!shelby!neon!torrie
From: torrie@cs.stanford.edu (Evan J Torrie)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: How do we change the scheduler? (Was Re: Multitasking at home...)
Message-ID: <1991Jan23.213736.28220@Neon.Stanford.EDU>
Date: 23 Jan 91 21:37:36 GMT
References: <1991Jan18.231330.16290@Neon.Stanford.EDU> <7553@sugar.hackercorp.com>   <1991Jan21.004720.25985@ncsuvx.ncsu.edu> <12880@life.ai.mit.edu>   <1991Jan21.072642.23587@Neon.Stanford.EDU> <10620.tnews@templar.actrix.gen.nz>  <1991Jan22.215801.4557@Neon.Stanfor
Sender: torrie@Neon.Stanford.EDU (Evan James Torrie)
Organization: Computer Science Department, Stanford University
Lines: 61

jbickers@templar.actrix.gen.nz (John Bickers) writes:

>Quoted from <1991Jan22.215801.4557@Neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan J Torrie):
>>   Can you explain the "input handling" task?  Do programs spin off an
>> input-handler thread (this is how OS/2 programs are written if I

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

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

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

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

-- 
------------------------------------------------------------------------------
Evan Torrie.  Stanford University, Class of 199?       torrie@cs.stanford.edu   
Fame, fame, fame...  What's it good for?  Ab-so-lute-ly nothing