Legacy Document

Inside Macintosh: Processes

Chapter 1 - Introduction to Processes and Tasks / About Tasks

Task Scheduling

As previously indicated, your interrupt tasks are executed in response to an interrupt. Because the execution of an interrupt task is not tied to the normal execution of your application, that task might continue to be executed even when your application is not itself executing. For example, all Time Manager tasks installed by your application continue to be executed as scheduled, whether or not your application is still the current application.

If it doesn't make sense to continue executing a particular Time Manager task when your application is no longer receiving processing time, you need to disable the execution of that task whenever your application is switched out and then reenable the task when your application regains control of the CPU. To disable a Time Manager task, you can remove its entry from the Time Manager queue. To reenable it, reinstall its entry in the queue.

In some cases, the Operating System automatically disables some of your application's interrupt tasks when your application is switched out. All VBL tasks installed by the Vertical Retrace Manager routine VInstall (which are known as system-based VBL tasks) are disabled whenever the installing application loses control of the CPU, if the address of the task is in the application partition. If you want to continue executing a system-based VBL task when your application is switched out, you must make sure that the address of the task is in the system partition. See the chapter "Vertical Retrace Manager" in this book for details on how to accomplish this.

Note

A VBL task installed by the routine SlotVInstall (known as a slot-based VBL task) is always executed as scheduled, regardless of the task's address. ·

When an interrupt task is executed, the Operating System does not always restore the installing application's context. As a result, you might not be able to read any application-specific system global variables from within the task. In addition, the task will not have access to any application-installed patches (which are part of its context). If your interrupt task depends on any part of your application's context, it should call the Process Manager function GetCurrentProcess to make sure that your process is currently in control of the CPU and hence that its context is valid.

Note

Your interrupt code must also avoid calling traps that access application-specific system global variables, unless you determine that your application's context is valid. In general, however, there is no way to determine whether a trap accesses system global variables. ·

Even if your application's context is not valid, you can still access some information in your application's partition if you suitably set up and restore the A5 register within your interrupt task. Your application global variables and your application's jump table are both accessed via an address in the microprocessor's A5 register. If you need to read or write any of your application's global variables or call routines in another segment, you must set up the A5 register with your application's value of the CurrentA5 global variable. Because you cannot in general inspect CurrentA5 at interrupt time, you need to read its value at noninterrupt time and pass the value to your interrupt routine. See the chapters "Time Manager" and "Vertical Retrace Manager" in this book for illustrations of a technique you can use for this purpose. For more information on how to set the A5 register properly, see the chapter "Memory Management Utilities" in Inside Macintosh: Memory.

If you do call routines in another code segment at interrupt time, you must make sure that the segment is already loaded in memory. Otherwise, the Operating System will call the Segment Manager to load the segment into memory, which could cause memory to be allocated.

WARNING

Interrupt tasks should never directly or indirectly cause memory to be allocated, moved, or purged, because the heap might be in an inconsistent state when the task is executed. ·

For this same reason, your interrupt tasks must never depend on the validity of handles that are not locked. The interrupt task might be called in the middle of a memory-allocation request, during which time the Memory Manager might be moving an unlocked block in the heap. If you must access relocatable blocks of heap memory within an interrupt task, make sure to lock those blocks before installing the task.

If virtual memory is available in the current operating environment, you also need to make certain that your interrupt tasks do not attempt to read information in a page of memory that might not be resident in physical RAM. Otherwise, the Operating System will attempt to read the affected pages of memory into physical RAM, which is likely to cause the system to crash. To be safe, you should hold all data and code accessed at interrupt time in physical memory. For details, see the chapter "Virtual Memory Manager" in Inside Macintosh: Memory.