Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!rpi!bu.edu!dartvax!eleazar.dartmouth.edu!llama
From: llama@eleazar.dartmouth.edu (Joe Francis)
Newsgroups: comp.sys.mac.programmer
Subject: Re: doing real work at interrupts
Summary: Why Patch SystemTask?
Keywords: spam spam spam Systemtask spam Tasks spam spam
Message-ID: <25479@dartvax.Dartmouth.EDU>
Date: 1 Nov 90 15:55:43 GMT
References: <2303@heavens-gate.lucid.com> <1990Oct30.131140.10113@hellgate.utah.edu> <4249.272ea016@cc.curtin.edu.au>
Sender: news@dartvax.Dartmouth.EDU
Organization: Dartmouth College, Hanover, NH
Lines: 43

In article <4249.272ea016@cc.curtin.edu.au> Peter Lewis writes:

>In article <1990Oct30.131140.10113@hellgate.utah.edu> Lee Choquette writes:

>> The main disadvantage to this scheme is that such drivers won't get
>> called when the application is not calling SystemTask or WaitNextEvent,

>   If you don't mind waiting until SystemTask is called, you could patch
>SystemTask at the same time as you install your interupt handler.  Then
>you could have the interupt handler set a variable (PC relative) to true
>when the interupt occurs, and have your SystemTask patch test this and
>do the interupt handling if it is true, and then call SystemTask.


I must be missing something here.  If you are only going to process pending
tasks when you can make an explicit call (in this case SystemTask), why
patch a ToolBox trap to do it?

Just write MySystemTask:

extern long taskToDo;

void MySystemTask()
{
   SystemTask();
   switch (taskToDo) {
     case doNothing:
        break;
     case pukeOnUser:
        DoPukeOnUserTask();
        break;
     case eraseDrive:
        DoEraseDriveTask();
        break;
     .
     .
     .
     default:
        MyError(kBadTaskIDString);
}

----------------------------------------------------------------------------
"Read My Lips: No Nude Texans!" - George Bush clearing up a misunderstanding