pab@lucid.com (Peter Benson) (10/31/90)
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 hing to have is a call that effectively says "call this function with these arguments at the next possible opportunity." "The next possible opportunity" would be right away if no uninterruptible operations were in progress, or it would be at the end of the ongoing uninterruptible operation. At the system level all this requires is knowing exactly what operations are uninterruptible, setting a flag at the beginning of them, and checking a queue at the end of them. Also the queue needs to be maintained in an atomic fashion. There would be times when it would just fail (queue is full, or another queue operation already in progress) , but it can certainly return a status to indicate that. There would have to be some restrictions on what kind of data could be passed in too, since direct pointers to movable memory would be an obvious no-no. I'm pretty new to Mac hacking. Maybe something somewhat like this already exists. Is there a problem with this. Could it be done with lots of patches? -ptr- pab@lucid.com
kurash@quimby.dartmouth.edu (Mark Valence) (11/02/90)
I think what you are looking for is the Notification Manager. The routines _NMInstall and _NMRemove are both accessible during interrupt time, so your interrupt can place a (pre-allocated) NMRec onto the notification queue. One of the fields of this record is nmCompletion, which is a ProcPtr to a procedure to run. This proc is executed during SystemTask, so it can allocate more memory, dispose stuff, draw to the screen, POST A MESSAGE, oooh, lot's of good stuff. See Tech Note #184. About using NewPtr, NewHandle, DisposXxx during interrupts: Why don't you just allocate a bunch of memory at INIT time (when you install your interrupt routine), and do your own memory management? I mean, it doesn't buy you anything tos use handles in this circumstance, and pointers are not very hard to implement (I mean the pointer routines aren't hard). This way, you could even optimize your allocation/deallocation routines to suit your exact purposes (maybe ever block is the same size, maybe allocated blocks are deallocated in FIFO order, etc.) Mark.