Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!jb10320
From: jb10320@uxa.cso.uiuc.edu (Desdinova)
Newsgroups: comp.sys.apple2
Subject: Re: GS multitasking
Message-ID: <1990Oct9.010137.22766@ux1.cso.uiuc.edu>
Date: 9 Oct 90 01:01:37 GMT
References: <9010080345.aa20655@generic.UUCP>
Sender: news@ux1.cso.uiuc.edu (News)
Organization: University of Illinois at Urbana
Lines: 45

In article <9010080345.aa20655@generic.UUCP> ericmcg@pnet91.UUCP (Eric Mcgillicuddy) writes:
>
>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

You're right, the toolbox isn't re-entrant (it SHOULD be, we have to push
parameters on the stack...)  There is already the BUSY flag which does basically
what you suggest, "locking" out processes from the tools if one is inside
already.  A better solution would include putting waiting processes on a queue
automatically, instead of making the calling process check for a "busy" error,
then put itself on the queue.  That's the way it's currently supposed to be
done. BTW, the 'queue' is a static array of length 4.  Not terribly useful
for extensions such as we are debating.  A process queue manager would 
definitely be in order.

I believe MouseDown records the current X & Y mouse positions at the time
of the event.  The wonderful Apple II programmers who designed the GS
toolbox (after seeing the faults of the Mac toolbox) did almost everything
right.  My gripes are not important, since they really only apply to
multiprogramming and GS/OS & ToolBox weren't designed for that.

Oh, I misread what you said about locking out switches.  Since the toolbox is
part of the "kernel", it is more than reasonable to disable switching inside
it.

--
Jawaid Bazyar               | Blondes in big black cars look better wearing
Senior/Computer Engineering | their dark sunglasses at night. (unk. wierdo)
jb10320@uxa.cso.uiuc.edu    |      The gin, the gin, glows in the Dark!
                            |                             (B O'Cult)
Apple II Users Unite! Storm the New Product Announcement and Demand Justice!