Updated 2013-12-15 18:53:17 by RLE

http://www.purl.org/tcl/home/man/tcl8.5/TclCmd/update.htm
update ?idletasks?

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.

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:

  • Keeping the GUI alive while some long-running calculation is executing. See Countdown program for an alternative.
  • Waiting for a window to be configured before doing things like geometry management on it. The alternative is to bind on events such as <Configure> that notify the process of a window's geometry. See Centering a window for an alternative.

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.

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.
    e.g. updateEvents timers will allow background timers to fire
    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 optionIndex;
    int flags = 0;
    static char *updateOptions[] = {"windows","files","timers","idle",
      "all", (char *) NULL};
    enum updateOptions
    {
       WIN_EVENTS, FILE_EVENTS, TIMER_EVENTS, IDLE_EVENTS,ALL_EVENTS
    };
   
    if (objc == 1)
    {
       flags = TCL_ALL_EVENTS|TCL_DONT_WAIT;
    }
    else if (objc == 2)
    {
       if (Tcl_GetIndexFromObj(interp, objv[1], updateOptions,"option",
         0, &optionIndex) != TCL_OK)
       {
          return TCL_ERROR;
       }
       switch ((enum updateOptions) optionIndex)
       {
          case WIN_EVENTS: {
                flags = TCL_WINDOW_EVENTS|TCL_DONT_WAIT;
                break;
             }
          case FILE_EVENTS: {
                flags = TCL_FILE_EVENTS|TCL_DONT_WAIT;
                break;
             }
          case TIMER_EVENTS: {
                flags = TCL_TIMER_EVENTS|TCL_DONT_WAIT;
                break;
             }
          case IDLE_EVENTS: {
                flags = TCL_IDLE_EVENTS|TCL_DONT_WAIT;
                break;
             }
          case ALL_EVENTS: {
                flags = TCL_ALL_EVENTS|TCL_DONT_WAIT;
                break;
             }
          default: {
                panic("Tcl_UpdateObjCmd: bad option index to updateEvents");
             }
       }
    }
    else
    {
       Tcl_WrongNumArgs(interp, 1, objv, "?windows | files | timers | idle | all?");
       return TCL_ERROR;
    }
   
    while (Tcl_DoOneEvent(flags) != 0)
    {
       /* Empty loop body */
    }
    /*
       Must clear the interpreter's result because event handlers could
       have executed commands.
     */
    Tcl_ResetResult(interp);
    return TCL_OK;
   }


Update performence issue with pthreads

Alexandre Ferrieux answered on 2012-02-06 on tcl-core to a post by Brian Griffin "Pthread+NotifierThreadProc problem": [1]

See event-oriented programming.