All Manuals > LispWorks IDE User Guide > 11 The Debugger Tool


11.11 Handling of Cocoa Event Loop hanging

This section applies to LispWorks for Macintosh only.

The Cocoa GUI is handled in one process (the "Cocoa Event Loop") and therefore code that makes this process wait (for example mp:process-wait, cl:sleep, mp:mailbox-read) causes the entire GUI to hang. In general, such functions should not be used on the Cocoa Event Loop (which includes callbacks), unless the wait is very short.

The situation is especially bad if the Cocoa Event Loop is waiting for another process, and then that other process gets an error. In this case, the other process will try to display a notifier window, and wait for the Cocoa Event Loop to do it, and there is a deadlock.

To avoid this problem, the LispWorks IDE has a mechanism that uses a timer and checks for just hanging. The mechanism checks, and if it looks like the main process hangs, it interrupts it. That causes a notifier window to appear, the GUI to update, and you can then check what went wrong.

In general, you should fix your code to avoid hanging of the Cocoa Event Loop.

This mechanism is in force only in the LispWorks IDE. Delivered applications need to avoid such hanging.

The mechanism is controlled by two parameters:

Notifier break interval

If a notifier tries to display and the Cocoa Event Loop did not respond in this interval, the Cocoa Event Loop is interrupted. That causes two notifiers to appear: first a notifier for the Cocoa Event Loop stating that it was interrupted because it hangs and there was an error on another process, and then the notifier that initially tried to display. You can then deal with the situation.

Check interval

The check to determine the above happens each check interval.

LispWorks IDE User Guide (Unix version) - 12 Feb 2015