Up to this point, two important widget implementation issues have been ignored. The first will be introduced by way of a simple senario.
Suppose many widgets distributed across many edm screens are connected to a number of pvs. The values of these pvs can change quite rapidly, perhaps several thousand times per second. The display manager cannot hope to update the X Window display at this rate, and even if it could, doing so would simply be a waste of resources. For this reason, edm widgets are designed to cache all process variable events to be processed at a later time. The widget function called by the display engine to achieve this deferred processing is named executeDeferred. A widget then, simply saves some data and sets a flag in a process variable callback function. Later, when the executeDeferred method is invoked, the graphical image is updated. This deferred processing occurs at most every 1/20 of a second. Some widgets use X Window timers to further throttle X I/O updates.
Another implementation issue involves uncertainty in the incorporation of future process variable implementations. Other toolkits and products may deliver events in the context of a different thread. Process variable callbacks should therefore perform only simple tasks like copying data values to class members and queueing a request for deferred processing within the protection of a simple locking protocol. The example code will illustrate the manner in which this is accomplished.