Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!comp.vuw.ac.nz!actrix!templar!jbickers
From: jbickers@templar.actrix.gen.nz (John Bickers)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: How do we change the scheduler? (Was Re: Multitasking at home...)
Message-ID: <10811.tnews@templar.actrix.gen.nz>
Date: 27 Jan 91 05:13:35 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.Sta
Organization: TAP, NZAmigaUG.
Lines: 77

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

>   How does a program become an input handler?  I presume you can spawn
> off a task, and tell it to be an input handler...   

    You don't start a seperate task. You usually have the handling routine
    inside your program, and call an OS routine to add a pointer to your
    code to the list. This is adding your code to an existing task
    (the input.device), which you then communicate with.

    A similar mechanism is used to add interrupt handlers.

    When the input.device processes an event, it gets the raw data,
    constructs a message, and then executes this list of handlers. So
    your code will be executed as part of the input.device task. This
    means the programmer needs to pay attention to what stack and local
    variables their handler expects to be using. Not hard.

    There are at least three ways the handler can communicate with the
    rest of your program: use shared variables (ie: the input.device
    task would be reading/writing your program's data space), use task
    signals, use messages.

>   What is the "normal mechanism"?

    Someone else explained IDCMPs. One of the input handlers in the
    list belongs to ("is", in a way) Intuition. Intuition gets the event,
    converts it into an Intuition event, then if it's meaningful to do
    so, passes it to the active user program IDCMP (ie: the active
    window).

>   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

    Yes, this is what happens. The application will be waiting for a
    message indicating that the user has fiddled with a "proportional
    gadget", and while the message will get queued up at the high
    input.device priority, the application will process it at whatever
    rate it is trekking at.

>   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. The user solution is to raise the priority of the application.
    The application design solution would be to use several tasks, one
    to do the data munging, and a higher priority one to handle the
    interface.

    Note that interactive tasks (like editors) tend to spend most of
    their time in the "wait" list, so it's ok to run them at a high
    priority if you wish to. While they are waiting for events, they
    have negligible effect on other tasks in the system.

>   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

    I don't believe there is a good OS solution. A user may not want
    a download halted while their word-processor scrolls its display
    a bit faster.

    Or whatever. The interactions involved between Intuition and all the
    tasks involved seem too complicated to me for an OS solution to be
    practical. A user can send time-consuming events to a number of
    tasks at the same time, for example. No, I'd leave this for the user
    to decide with something like Xoper, and only make broad assumptions
    at the application design level.

> Evan Torrie.  Stanford University, Class of 199?       torrie@cs.stanford.edu   
--
*** John Bickers, TAP, NZAmigaUG.        jbickers@templar.actrix.gen.nz ***
***         "Patterns multiplying, re-direct our view" - Devo.          ***