As already mentioned in section 3.6, Tk events must be polled to assure interactivity. When the Tcl/Tk toolkit is used only as a part of the GUI and the application spends most of the time in executing Prolog and possibly external code, it is very important to use the proper approach to handle events.
It turns out that there are two basic approaches to event handling, either Prolog or Tcl/Tk is the master (client) and the best and cleanest strategy is not to mix these two approaches. These limitations are due to possible problems with non-reentrant Tcl/Tk code. The ECLiPSe code is fully reentrant and can be at any time interrupted to call a new Prolog predicate. For Tcl/Tk this is not quite the case (or at least it was not the case with Tk 3.6) and programs that did not comply with the above rules sometimes crashed with enigmatic error messages. Another reason is that when Tcl/Tk and Prolog recursively call each other, long programs may end up in very deeply nested calls which may potentially overflow the machine stack. Because of that, it is safer to avoid nested mutual calls between Tcl/Tk and Prolog by following the above rules.
In the following we describe both approaches and the ProTcXl primitives to be used for each one.