For advanced applications, you might have to suspend an execution until some condition is satisfied. The wait, notify and notifyAll methods of the org.zkoss.zk.ui.Executions class are designed for such purpose.

When an event listener want to suspend itself, it could invoke wait. Another thread could then wake it up by use of notify or notifyAll, if the application-specific condition is satisfied. The modal dialog is an typical example of using this mechanism.

public void doModal() throws InterruptedException {
    ...Executions.wait(_mutex); //suspend this thread, an event processing thread}    
public void endModal() {
...
    Executions.notify(_mutex); //resume the suspended event processing thread    
}

Their use is similar to the wait, notify and notifyAll methods of the java.lang.Object class. However, you cannot use the methods of java.lang.Object for suspending and resuming event listeners. Otherwise, all event processing will be stalled for the associated desktop.

Notice that, unlike Java Object's wait and notify, whether to use the synchronized block to enclose Executions' wait and notify is optional. In the above case, we don't have to, because no racing condition is possible. However, if there is an racing condition, you can use the synchronized block as what you do with Java Object's wait and notify.

//Thread 1
public void request() {
    ...    
    synchronized (mutex) {    
        ...//start another thread        
        Executions.wait(mutex); //wait for its completion        
    }    
}

//Thread 2
public void process() {
    ... //process it asynchronously    
    synchronized (mutex) {    
        Executions.notify(mutex);        
    }    
}