http://www.purl.org/tcl/home/man/tcl8.5/TclCmd/update.htm
The [update] command is used to bring the application “up to date” by entering the Tcl event loop repeatedly until all pending events (including idle callbacks) have been processed. KBK 2000-02-12: My personal opinion is that update is not one of the best practices, and a programmer is well advised to avoid it. I have seldom if ever seen a use of update that could not be more effectively programmed by another means, generally appropriate use of event callbacks. By the way, this caution applies to all the Tcl commands (vwait and tkwait are the other common culprits) that enter the event loop recursively, with the exception of using a single vwait at global level to launch the event loop inside a shell that doesn't launch it automatically. If the idletasks keyword is specified as an argument to the command, then no new events or errors are processed; only idle callbacks are invoked. This causes operations that are normally deferred, such as display updates and window layout calculations, to be performed immediately.
KBK (12 February 2000) -- My personal opinion is that the [update] command is not one of the best practices, and a programmer is well advised to avoid it. I have seldom if ever seen a use of [update] that could not be more effectively programmed by another means, generally appropriate use of event callbacks. By the way, this caution applies to all the Tcl commands (vwait and tkwait are the other common culprits) that enter the event loop recursively, with the exception of using a single [vwait] at global level to launch the event loop inside a shell that doesn't launch it automatically. The commonest purposes for which I've seen update recommended are: The commonest purposes for which I've seen [update] recommended are:
What's wrong with update? There are several answers. What's wrong with [update]? There are several answers. First, it tends to complicate the code of the surrounding GUI. If you work the exercises in the Countdown program, you'll get a feel for how much easier it can be when each event is processed on its own callback.
Second, it's a source of insidious bugs. The general problem is that executing update has nearly unconstrained side effects; on return from update, a script can easily discover that the rug has been pulled out from under it. There's further discussion of this phenomenon over at Update considered harmful. Second, it's a source of insidious bugs. The general problem is that executing [update] has nearly unconstrained side effects; on return from [update], a script can easily discover that the rug has been pulled out from under it. There's further discussion of this phenomenon over at Update considered harmful.
TFW (11 August 2003) Occasionlly we need to allow certain events to be processed while withholding others. To allow this I took the existing update implementation and modified it to allow allowable event types. For example, calling "updateEventObjCmd timers" allows timers that are scheduled to fire, but withholds gui updates. This can be very useful to work around some of the problems mentioned here.
/*
/*
----------------------------------------------------------------------
updateEventObjCmd --
Granular version of the Update command, can be used
to only allow certain events to occur.
without allow window updates to occur.
updateEvents windows will only allow other events to occur
if a window event was also processed.
Results:
A standard Tcl result.
Side effects:
See the user documentation.
----------------------------------------------------------------------
*/
static int
updateEventObjCmd
(
ClientData clientData,
Tcl_Interp *interp,
int objc,
Tcl_Obj *CONST objv[]
) {
int flags = 0;
static char *updateOptions[] = {"windows","files","timers","idle",
"all", (char *) NULL};
"all", (char *) NULL};
{
WIN_EVENTS, FILE_EVENTS, TIMER_EVENTS, IDLE_EVENTS,ALL_EVENTS
WIN_EVENTS, FILE_EVENTS, TIMER_EVENTS, IDLE_EVENTS,ALL_EVENTS
if (objc == 1)
{
flags = TCL_ALL_EVENTS|TCL_DONT_WAIT;
flags = TCL_ALL_EVENTS|TCL_DONT_WAIT;
else if (objc == 2)
{
if (Tcl_GetIndexFromObj(interp, objv[1], updateOptions,"option",
if (Tcl_GetIndexFromObj(interp, objv[1], updateOptions,"option",
0, &optionIndex) != TCL_OK)
{
return TCL_ERROR;
}
switch ((enum updateOptions) optionIndex)
{
case WIN_EVENTS: {
break;
}
}
case FILE_EVENTS: {
break;
}
}
case TIMER_EVENTS: {
break;
}
}
case IDLE_EVENTS: {
break;
}
}
case ALL_EVENTS: {
break;
}
}
default: {
}
}
}
else
{
Tcl_WrongNumArgs(interp, 1, objv, "?windows | files | timers | idle | all?");
Tcl_WrongNumArgs(interp, 1, objv, "?windows | files | timers | idle | all?");
return TCL_ERROR;
while (Tcl_DoOneEvent(flags) != 0)
{
/* Empty loop body */
/* Empty loop body */
/*
Must clear the interpreter's result because event handlers could
Must clear the interpreter's result because event handlers could
have executed commands.
*/
return TCL_OK;}
}
Alexandre Ferrieux answered on 2012-02-06 on tcl-core to a post by Brian Griffin "Pthread+NotifierThreadProc problem":
[L1 ]
See event-oriented programming.