Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!pnet91.UUCP!ericmcg
From: ericmcg@pnet91.UUCP (Eric Mcgillicuddy)
Newsgroups: comp.sys.apple2
Subject: GS multitasking
Message-ID: <9010080345.aa20655@generic.UUCP>
Date: 8 Oct 90 03:32:05 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 40

>   Wrong.  Most of the time the GS is spending CPU power doing the following
busy wait:

EventLoop:
   Mouse?  Nope.
   Keyboard?  Nope.
   goto eventloop

[more..]
   Time slicing and process management would increase the effective throughput
of the CPU by not busy-waiting.  Any process calling GetNextEvent would be
blocked until its input came thru.  Note this is a step better than
MultiFinder
or LeapFrog, which just cycle the busy wait through multiple processes.
   Time Slicing and process management will make the GS work faster.

>UUCP: bkj386!pnet91!ericmcg
>INET: ericmcg@pnet91.cts.com


--
Jawaid Bazyar               | Blondes in big black cars look better wearing
<

Suppose every Heartbeat (1/60th of a second), after hearbeat tasks are
handled, the active process is swapped? Obviously only the forground task
requires user input, so input need only be Queued up awaiting the forground
task to begin operating after some later heartbeat. The GS queues all ADB
inputs, but has trouble with double clicks, s othis is fairly easy to do. 

The question is: What if GetNextEvent returns MouseDown, but then a task
switch occurs? is the mouse poisition unchanged when the process it running
again? 

I understand that the Toolbox is not re-entrant, so locking out a switch
during ToolCalls seems like a reasonable precaution. Would this cause more
problems than it solves?

UUCP: bkj386!pnet91!ericmcg
INET: ericmcg@pnet91.cts.com