Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zaphod.mps.ohio-state.edu!rpi!uwm.edu!bionet!agate!usenet.ins.cwru.edu!ukma!rex!mandel@vax.anes.tulane.edu
From: mandel@vax.anes.tulane.edu (Jeff E Mandel MD MS)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Application defined events in Multifinder
Message-ID: <6382@rex.cs.tulane.edu>
Date: 28 Feb 91 14:56:05 GMT
References: <1CE00001.ieuttv@tbomb.ice.com> <1244@duteca4.UUCP>
Sender: news@rex.cs.tulane.edu
Organization: Tulane University School of Medicine
Lines: 38

In article <1244@duteca4.UUCP> thomas@duteca (Thomas Okken) writes:
>> In article <1991Feb23.140420.20707@ux1.cso.uiuc.edu>,
resnick@cogsci.uiuc.edu (Pete Resnick) writes:
>>> I can't seem to find any documentation on this one. It appears that
>>> PostEvent can be called at interrupt, so that I can post app1Evt's
>>> from asynchronous completetion routines in my program to signal that
>>> events have occurred. It is not clear, however, how I am to distinguish
>> 
>> I believe that with the advent of MultiFinder, applications are not
>> supposed to be using the appEvt's. Unfortunately, I do not have my
>> MF Doc at hand...
>
>Well, I don't remember offhand where I read this - must've been either
>"Programmer's Guide to MultiFinder" or some technote, but the answer is:
>You can't use app[1-4]evts under MultiFinder, because all events will be
passed
>to the foreground application. So if your app is in the background, waiting
>to be notified by an app1evt (to be posted by a VBL task doing some useful
>thing), it can wait forever: the app1evt is sent to the foreground app, which
>will probably ignore it.
>If communication between an interrupt-time task an your application is needed,
>use globals as semaphores. Have fun trying to keep track of A5! ;-)
>
I have struggled with the problem of passing messages from interrupt-time to
eventLoop-time, and my conclusion was that the best solution is to implement
your own private event queue as an OSqueue, and have your own routine which
does the equivalent of GetNextEvent. I call this routine on null event, and in
a DragHook and MenuHook, allowing real-time processes to get serviced even if
the user is inconsiderately mousing down when real-time events are occuring. If
someone dies and leaves me a month of free time in their will, I think it would
make a great INIT to patch the traps that can keep control during mousing so
that a real-time process can run on a Mac. Maybe I could win an Apple keychain
in the MacHack Hack contest for it.

Jeff E Mandel MD MS
Asst Professor of Anesthesiology
Tulane University School of Medicine
New Orleans, LA