Path: utzoo!attcan!uunet!timbuk!cs.umn.edu!msi.umn.edu!src.honeywell.com!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!wuarchive!udel!princeton!twg.com!lefty
From: lefty@twg.com ("Lefty")
Newsgroups: comp.sys.mac.programmer
Subject: Re: doing real work at interrupts
Message-ID: <8223@gollum.twg.com>
Date: 6 Nov 90 00:45:39 GMT
Sender: news@twg.com
Organization: Interessengemeinschaft Maas-NeoTek
Lines: 31
References:<1990Oct30.152816.2172@cs.umu.se> <2303@heavens-gate.lucid.com> <1990Oct30.131140.10113@hellgate.utah.edu> <1185@skye.cs.ed.ac.uk>

In article <1185@skye.cs.ed.ac.uk> nick@cs.edinburgh.ac.uk (Nick Rothwell) 
writes:
> In article <1990Oct30.131140.10113@hellgate.utah.edu>, 
u-lchoqu%peruvian.utah.edu@cs.utah.edu (Lee Choquette) writes:
> > In article <2303@heavens-gate.lucid.com> pab@lucid.com (Peter Benson) 
writes:
> > >
> > > It seems like what is needed is a general mechanism whereby any sort of
> > > task can be initiated at interrupt level.  This would have to be done by
> > > apple, but the right thing to have is a call that effectively says "call
> > > this function with these arguments at the next possible opportunity."
> > 
> > How about opening a "device driver" that doesn't actually do any
> > reading or writing to a device, but has its "dNeedTime" flag set,
> 
> 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.

Actually, an _real_ easy way to do this is to use Apple's Notification 
Manager.  Set up an "invisible" notification (i.e. no icon, no sound, no 
dialog), and do the work necessary in the notification proc.

I've tried it; real easy to do, and it works just fine.  My application 
was a requirement to release a block of memory in response to an 
interupt-level event.


--
Lefty  (lefty@twg.com)                        "And you may ask yourself,
DoD # 0152                                       'How do I work this?'"