The system view
In Smalltalk images that include a user interface (Common Widgets), the startUp class (System startUpClass) is responsible for providing a polling loop for the user interface process, an instance of UIProcess. The UIProcess sends the message messageLoop to the startUp class to start the polling loop. The startUp class, EsWindowSystemStartUp, implements a simple polling loop similar to the one shown below:
messageLoop
"Run the dispatch loop."
true] whileTrue: [
CwAppContext default readAndDispatch
ifFalse: CwAppContext default sleep ]]
In general, application programmers never need to modify this code because it provides full functionality for all but the most exceptional circumstances. However, as mentioned above, application programmers can replace this loop with their own.
The message loop makes use of two methods defined in class CwAppContext:
readAndDispatch
Reads a single event, if one is available, from the underlying operating system, dispatches it to the appropriate widget, and handles any callbacks that occur. In addition, it handles any pending requests for user interface operations by non-UI processes, as shown below. Finally, it returns true if an event was processed and false otherwise.
sleep
Checks for user interface activity, and if none, removes the UIProcess from the ready-to-run queue. The system assumes there is user interface activity in the following cases:
•There are events to process
•There are background user interface requests to be run
•There are work procs registered
•There are timer procs registered
As long as there is any activity in the user interface, the UIProcess will continue to poll for events as quickly as possible. As soon as the activity stops, the UIProcess becomes inactive and suspends. This enables any other Smalltalk processes that are running at the the same or lower priority than the UIProcess to execute.
Because sending CwAppContext messageLoop can deactivate the UIProcess, there must be a mechanism for reactivating it. To support this, sleep enables an operating-system-specific mechanism that causes the private message CwAppContext default wake to be sent when new events become available. This wake method is also sent by all other methods that generate user interface activity, causing the UIProcess to respond immediately.
If the underlying operating system does not provide any mechanism for triggering user-written code when events become available, the CwAppContext can still function by generating a Smalltalk process that wakes the UIProcess at regular intervals. By default, this is called the "CwAsyncIOProcess".
As previously mentioned, if there is no user interface activity the UIProcess is deactivated, enabling other Smalltalk processes at the same or lower priority to run. However, if there are no other active processes to run, a system-provided "idle" process is run, which repeatedly sends the suspendSmalltalk message to the default CwAppContext:
suspendSmalltalk
Suspends the entire VA Smalltalk system, using an operating-system-specific facility, until there is event activity. When the VA Smalltalk system is suspended it consumes little or no processor resources. Under multitasking operating systems this enables other applications full access to the CPU.
As soon as input is available, both the VA Smalltalk system and the UIProcess are reactivated, because they are higher priority than the idle process.
If the operating system does not provide a facility for suspending execution of an application until input is available, the suspendSmalltalk method simply returns to its sender. In this case, Common Widgets continues to run normally, but VA Smalltalk competes for resources with any other applications being run by the operating system.
Note that there is an interaction between the suspendSmalltalk method and the Smalltalk Delay class. If the idle process runs because a higher priority process has suspended on a Delay, the system must be reactivated when the Delay expires. This situation is handled in one of three ways depending on the capabilities of the operating system:
•With operating systems where the Delay class uses the same mechanism that suspendSmalltalk uses to detect input activity, the system is reactivated with no further intervention.
•With operating systems where Delay uses a different mechanism than suspendSmalltalk, but it is possible for a user written application to post a user interface event, this facility is used to reactivate the system.
•If neither of the above mechanisms are available, VA Smalltalk checks for Delays and deactivates the system only when there are none pending.
Last modified date: 01/29/2015