Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!smurf!urlichs
From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: comp.sys.mac.programmer
Subject: Re: doing real work at interrupts
Message-ID: <3a53g2.]53@smurf.sub.org>
Date: 2 Nov 90 13:32:24 GMT
References: <1990Oct30.131140.10113@hellgate.utah.edu> <1185@skye.cs.ed.ac.uk> <25478@dartvax.Dartmouth.EDU>
Organization: University of Karlsruhe, FRG
Lines: 23

In comp.sys.mac.programmer, article <25478@dartvax.Dartmouth.EDU>,
  llama@eleazar.dartmouth.edu (Joe Francis) writes:
< 
< In article <1185@skye.cs.ed.ac.uk> nick@lfcs.ed.ac.uk writes:>
< Why bother? Just declare a static circular buffer, have the interrupt
< >routine place messages into it in some format, and have the main
< >application examine it somewhere in the event loop.
< 
< An even simpler (in my opinion) solution is for the interrupt handler to
< post events to the app.  PostEvent() and PPostEvent() are not on the
< "forbidden interupt time ToolBox calls" list.  Can anyone confirm they are
< indeed safe in this situation?
< 
PostEvent is in fact safe -- but there's another problem:
Who says that _your_ application is going to receive these events?
Under MultiFinder, it doesn't matter which app is applciation posts these
events -- the frontmost application gets them.
The user might even switch programs between your PostEvent() and the next
WaitNextEvent().

-- 
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de     /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330)   \o)/