Important: The information in this document is obsolete and should not be used for new development.
VBL Tasks and Application ExecutionOften, a VBL task performs services that are useful only to the application that installed it. For instance, consider the VBL task defined in "Spinning the Cursor" beginning on page 4-16. This task spins the cursor while your application performs some lengthy operation and should be executed only if your application is in the foreground. If the user switches your application into the background while it is occupied with that lengthy operation, you probably want to disable that task for as long as your application is in the background. Otherwise, the cursor will continue to spin, probably confusing
In other cases, a VBL task should continue to be executed even when the application that installed it is no longer in the foreground. For instance, you probably wouldn't want to disable a VBL task that periodically checks for the arrival of electronic mail just because your application is moved to the background.
The Process Manager automatically disables a system-based VBL task when the application that installed it is swapped out in a major or minor switch, if the address of the VBL task is anywhere in the application's partition. Then, when that application regains control of the processor, the Process Manager reenables that VBL task. If, however, the address of a system-based VBL task is in the system partition, the VBL task continues to be executed, regardless of the processing status of the application that launched it.
The address of a system-based VBL task, not the address of the VBL task record, determines whether the Process Manager disables the task. See "Installing a Persistent VBL Task," beginning on page 4-20, for a technique you can use to prevent the disabling of a task when the application that installed it is switched out.
- When your system-based VBL task continues to be executed in this way, the Process Manager does not restore the context of your application before executing the VBL task. In particular, any trap patches installed by your application might not be available to the VBL task. When a VBL task depends on your application context, your task can call the Process Manager function
GetCurrentProcessto check whether your application is the current process and hence that its context is valid. ·
By contrast, the Process Manager never disables a slot-based VBL task, no matter where the task is located. As a result, if you want to disable a slot-based VBL task when your application is in the background, you must do so yourself, either by removing the task record from the VBL queue or by setting the
vblCountfield of the task record to 0. You can do this in response to a suspend event. Then, when your application receives a resume event, you can reenable the VBL task by reinstalling the task record or by resetting the
vblCountfield of the task record to the appropriate value.
In some cases, you might want to disable a system-based VBL task manually, even though the Process Manager also disables it when your application is switched out. This is because the Process Manager reenables system-based VBL tasks when your application receives processing time as a result of a minor switch, when your application is still in the background. If the VBL task should be executed only when your application is in the foreground, you need to disable it when your application receives a suspend event and reenable it when your application receives a resume event. The easiest way to do this is to set and reset the
vblCountfield of the task record, as described in the previous paragraph.
The Process Manager treats VBL tasks slightly differently when your application quits or crashes than when it is switched out. If either the task record for a VBL task or the code of the VBL task is located in your application partition, the Process Manager removes that task record from its VBL queue. (This is true for both slot-based and system-based VBL tasks.) Conversely, if both a VBL task record and the task itself are located in the system partition, the Process Manager doesn't remove the task record from its VBL queue when the application that installed them quits or crashes.
- Failure to remove VBL task records installed in the system partition from their queues can lead to a system crash if the VBL task is located in the system partition but accesses data in your application partition. Because the Process Manager deallocates your application partition when your application quits or crashes, the VBL task may attempt to access undefined data. The easiest way to avoid this problem is to patch the Process Manager's
ExitToShellprocedure so that it removes all VBL task records installed by your application. ·