Legacy Document

Inside Macintosh: Processes

Chapter 1 - Introduction to Processes and Tasks / About Processes

Process Scheduling

Your application can yield control of the CPU to other processes only at very specific times, namely when you call the Event Manager functions WaitNextEvent or EventAvail. Whenever your application calls one of these functions, the Process Manager checks the status of your process and takes the opportunity to schedule other processes.

Note

Your application can also yield processing time to other processes as a result of calling other Toolbox routines containing internal calls to WaitNextEvent or EventAvail. For example, your application can yield the CPU to other processes as a result of calling either of the Apple Event Manager functions AESend or AEInteractWithUser. See the chapter "Apple Event Manager" in Inside Macintosh: Interapplication Communication for information on using these two functions. ·

In general, your application continues to receive processing time as long as any events are pending for it. When your application is the foreground process, it yields time to other processes in these situations: when the user wants to switch to another application or when no events are pending for your application. Your application can also choose to yield processing time to other processes when it is performing a lengthy operation.

A major switch occurs when the Process Manager switches the context of the foreground process with the context of a background process (including the A5 worlds and application-specific system global variables) and brings the background process to the front, sending the previous foreground process to the background.

When your application is the foreground process and the user elects to work with another application (by clicking in a window of another application, for example), the Process Manager sends your application a suspend event if the acceptSuspendResumeEvents bit is set in your application's 'SIZE' resource. When your application receives a suspend event, it should prepare to suspend foreground processing, allowing the user to switch to the other application. For example, in response to the suspend event, your application should remove the highlighting from the controls of its frontmost window and take any other necessary actions. Your application is actually suspended the next time it calls WaitNextEvent or EventAvail.

After your application receives the suspend event and calls WaitNextEvent or EventAvail, the Process Manager saves the context of your process, restores the context of the process to which the user is switching, and sends a resume event to that process (if the acceptSuspendResumeEvents bit is set in its 'SIZE' resource). In response to a resume event, your application should resume processing and start interacting with the user. For example, your application should highlight the controls of its frontmost window.

A major switch also occurs when the user hides the active application (by choosing the Hide command in the Application menu). In general, a major switch cannot occur when a modal dialog box is the frontmost window. However, a major switch can occur when a movable modal dialog box is the frontmost window.

A minor switch occurs when the Process Manager switches the context of a process to give time to a background process without bringing the background process to the front. For example, a minor switch occurs when no events are pending in the event queue of the foreground process. In this situation, processes running in the background have an opportunity to execute when the foreground process calls WaitNextEvent or EventAvail. (If the foreground process has one or more events pending in the event queue, then the next event is returned and the foreground process again has sole access to the CPU.)

When an application is switched out in this way, the Process Manager saves the context of the current process, restores the context of the next background process scheduled to run, and sends the background process an event. At this time, the background process can receive either update, null, or high-level events.

A background process should not perform any task that significantly limits the ability of the foreground process to respond quickly to the user. A background process should call WaitNextEvent often enough to let the foreground process be responsive to the user. Upon receiving an update event, the background process should update only the content of its windows. Upon receiving a null event, the background process can use the CPU to perform tasks that do not require significant amounts of processing time.

The next time the background process calls WaitNextEvent or EventAvail, the Process Manager saves the context of the background process and restores the context of the foreground process (if the foreground process is not waiting for a specified amount of time to expire before being scheduled again). The foreground process is then scheduled to execute. If no events are pending for the foreground process and it is waiting for a specified amount of time to expire, the Process Manager schedules the next background process to run. The Process Manager continues to manage the scheduling of processes in this manner.

Drivers and vertical blanking (VBL) tasks installed in the system heap are scheduled regardless of which application is currently executing. Drivers installed in an application's heap are not scheduled to run when the application is not executing. See the section "Task Scheduling," beginning on page 1-11, for more information about the scheduling of interrupt tasks.

Note

See the chapter "Event Manager" in Inside Macintosh: Macintosh Toolbox Essentials for specific information on how your application can handle suspend and resume events and how your application can take advantage of the cooperative multitasking environment. ·

Whenever your application calls WaitNextEvent or EventAvail, the Process Manager checks the status of your process and takes the opportunity to schedule other processes. Using the WaitNextEvent function, you can control when your process is eligible to be switched out.

The sleep parameter of the WaitNextEvent function specifies a length of time, in ticks, during which the application relinquishes the CPU if no events are pending. For example, if you specify a nonzero value in the sleep parameter and no events are pending in your application's event queue when you call WaitNextEvent, the
Process Manager saves the context of your process and schedules other processes until an event becomes available or the time expires. Once the specified time expires or an event becomes available for your application, your process becomes eligible to run. At this time, the Process Manager schedules your process to run at the next available chance. (You can also call the Process Manager's WakeUpProcess function to make a process eligible to run before the time in the sleep parameter expires.) If the time specified by sleep expires and no events are pending for your application, the Process Manager sends your application a null event.

In general, you should specify a value greater than 0 in the sleep parameter so that those applications that need processing time can get it. If your application performs any periodic task, then the frequency of the task usually determines what value you specify in the sleep parameter. The less frequent the task, the higher the value of the sleep parameter. A reasonable value for the sleep parameter is 60.