maymudes@husc4.HARVARD.EDU (David M. Maymudes) (04/15/89)
I know that this is a "standard question", but:
If a routine is called at interrupt time, what is the best way for it to get
control back _not_ at interrupt time. The only methods I recall hearing about
are patching _GetNextEvent (and possibly _WaitNextEvent, but probably there
is one patch which will cover all cases) and using jGNEfilter, which is a
low-memory global, and thus bad. (Also, I don't know where it is documented.)
So is there a better way to do this? Failing that, what is the "accepted"
method? Thanks in advance for any information.
--David Maymudes
maymudes%husc4@harvard.ARPA maymudes@husc4.harvard.edu
maymudes@husc4.UUCP maymudes@HARVUNXU.BITNET
..{seismo, harpo, ihnp4, linus, allegra, ut-sally}!harvard!husc4!maymudes
davidm@harvarda.BITNETbob@accuvax.nwu.edu (Bob Hablutzel) (04/16/89)
> I know that this is a "standard question", but: > If a routine is called at interrupt time, what is the best way for it to get > control back _not_ at interrupt time. The only methods I recall hearing about > are patching _GetNextEvent (and possibly _WaitNextEvent, but probably there > is one patch which will cover all cases) and using jGNEfilter, which is a > low-memory global, and thus bad. (Also, I don't know where it is documented.) > So is there a better way to do this? Failing that, what is the "accepted" > method? Thanks in advance for any information. If the interrupt handler is part of an application, then you could always post an application defined event (Using PostEvent, on the page between IM-67 and IM-69 (can you tell what key on my keyboard doesn't work??)). > --David Maymudes Bob Hablutzel Wildwood Software BOB@NUACC.ACNS.NWU.EDU Disclaimer: My cat is fixed. My keyboard isn't.
lsr@Apple.COM (Larry Rosenstein) (04/19/89)
In article <10050101@accuvax.nwu.edu> bob@accuvax.nwu.edu (Bob Hablutzel) writes: > If the interrupt handler is part of an application, then you could always > post an application defined event (Using PostEvent, on the page between > IM-67 and IM-69 (can you tell what key on my keyboard doesn't work??)). You have to be careful if the interrupt handler can run while the application is not frontmost. In that case, the event would be posted into the frontmost application's event queue. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
darin@Apple.COM (Darin Adler) (04/20/89)
In article <1631@husc6.harvard.edu> maymudes@husc4.UUCP (David M. Maymudes) writes: > I know that this is a "standard question", but: > > If a routine is called at interrupt time, what is the best way for it to get > control back _not_ at interrupt time. The only methods I recall hearing about > are patching _GetNextEvent (and possibly _WaitNextEvent, but probably there > is one patch which will cover all cases) and using jGNEfilter, which is a > low-memory global, and thus bad. (Also, I don't know where it is documented.) > > So is there a better way to do this? Failing that, what is the "accepted" > method? Thanks in advance for any information. Depending on why you want to do this, there are two good ways. If your reason for wanting to get control is that you don't want to keep interrupts disabled for an unreasonably long time, you can use the Deferred Task Manager. This guarantees that your routine will be called with all interrupts enabled, but you still wont be able to use the Memory Manager, or most of the higher level toolbox routines. If you want to be able to use the toolbox, you can use the Notification Manager. The response routine for a notification is run at a "good" non- interrupt time, and as long as you set the other fields to 0 and nil, no notification (icon, sound, or dialog) will occur. Your "response routine" can do whatever is necessary. -- Darin Adler, System Software Scapegoat, Apple Computer Internet: darin@Apple.com UUCP: {nsc,sun}!apple!darin
darin@Apple.COM (Darin Adler) (04/20/89)
In article <10050101@accuvax.nwu.edu> bob@accuvax.nwu.edu (Bob Hablutzel) writes: > If the interrupt handler is part of an application, then you could always > post an application defined event (Using PostEvent, on the page between > IM-67 and IM-69 (can you tell what key on my keyboard doesn't work??)). This is a bad idea. Under MultiFinder (and possibly other future environments), a posted event goes the the frontmost application (at the time the event is posted). In many instances, this will not be the application that the interrupt handler is part of. For this reason, we discourage the use of application- defined events under MultiFinder. -- Darin Adler, System Software Scapegoat, Apple Computer Internet: darin@Apple.com UUCP: {nsc,sun}!apple!darin
ech@pegasus.ATT.COM (Edward C Horvath) (04/22/89)
> If a routine is called at interrupt time, what is the best way for it to get > control back _not_ at interrupt time. The only methods I recall hearing about > are patching _GetNextEvent (and possibly _WaitNextEvent, but probably there > is one patch which will cover all cases) and using jGNEfilter, which is a > low-memory global, and thus bad. (Also, I don't know where it is documented.) > --David Maymudes From article <10050101@accuvax.nwu.edu>, by bob@accuvax.nwu.edu (Bob Hablutzel): > If the interrupt handler is part of an application, then you could always > post an application defined event (Using PostEvent, on the page between > IM-67 and IM-69 (can you tell what key on my keyboard doesn't work??)). Depending on what you're trying to accomplish, you can use the Deferred Task Manager (IM V-465). Deferred tasks get held until there are no interrupts pending, just before return of control to the application. Otherwise, there's nothing for it but to set up a communications area in the DRVR's data area. If you're an isolated Vertical-retrace task you may be SOL. =Ned Horvath=