Path: utzoo!attcan!uunet!decwrl!sdd.hp.com!samsung!umich!yale!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.sys.apple2
Subject: Re: GS multitasking
Message-ID: <14066@smoke.BRL.MIL>
Date: 9 Oct 90 13:06:44 GMT
References: <9010080345.aa20655@generic.UUCP>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 18

In article <9010080345.aa20655@generic.UUCP> ericmcg@pnet91.UUCP (Eric Mcgillicuddy) writes:
>...  Any process calling GetNextEvent would be blocked until its input came
>thru.

I thought it already did block until an event in its event mask occurred?

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

This is one reason for not using preemptive scheduling.  Mouse events should
consist of combined button status + cursor location, precisely to avoid the
sort of situation you describe (which could occur even in a single-threaded
environment, if various aspects of the mouse are handled independently).

Not that it helps any with the IIGS, but to see one very nice solution to
the entire "problem", you should look up Rob Pike's papers on Plan 9 and
NewSqueak, published in various UNIX symposium proceedings.