I have a tk application which is modeled after wish that seems to have a
problem with screen updates when under a heavy input load. The problem occurs
whenever there is a large amount of input to be read from a socket which
is processed by function which is called via the file handler mechanism
provided via Tk_CreatFileHandler(). The function reads a single tcl command
from the socket and then calls Tcl_Eval to process the command. The screen
should be updated as a result of the tcl command due to the fact that it
invokes tk calls to add an entry to a scrollable list. Another process
sends the commands to my application. Under a certain scenario a flood
of commands are sent to the socket and causes a back log which causes my
app to seemingly continuously call the file handler to process a command.
During this flood of commands the list widget is not updated although I
know I am making tk calls which insert entries. I have tried doing an
XFlush() call in my file handler after the Tcl_Eval() call, but this
has no effect. The updates finally reach the screen after the flood of
input subsides. This may be more of an X question than tcl/tk but I thought
it might pertain to tk. Is there anything else I can do to cause the screen
to be updated as the commands arrive? The application works correctly in
an almost identical scenario where the commands come spaced further apart.

Here is a code skeleton that outlines my application structure:

please no syntax flames this is just to give a loose idea of functionality

main()
{
        interp = Tcl_CreateInterp();
        w = Tk_CreateMainWindow(interp, display, name);
        Tk_CreateFileHandler( id, TK_READABLE, fileHandlerProc, 0);
        Tk_MainLoop();

void
fileHandlerProc(
        ClientData clientData,          /* Not used. */
        int mask)                     /* event type mask */
{
        cmd = getTclCommandFromSocket();
        Tcl_Eval(interp, cmd, 0, (char **)NULL);
        XFlush(Tk_Display( w ));   /* this SHOULD flush request queue and cause
                                                  ** screen updates.
                                                  */

System particulars:
Tk 2.1
Tcl 6.3
SCO 3.2.2 ( also occurs under ISC 2.2 X server )

--
"These are not the views of StorageTek, so blame me."
Jeff Hanson                                /\    /\/\  
StorageTek - Louisville, Co.              /  \/\/  \ \

|> I have a tk application which is modeled after wish that seems to have a
|> problem with screen updates when under a heavy input load. The problem occurs
|> whenever there is a large amount of input to be read from a socket which
|> is processed by function which is called via the file handler mechanism
|> provided via Tk_CreatFileHandler(). The function reads a single tcl command
|> from the socket and then calls Tcl_Eval to process the command. The screen
|> should be updated as a result of the tcl command due to the fact that it
|> invokes tk calls to add an entry to a scrollable list. Another process
|> sends the commands to my application. Under a certain scenario a flood
|> of commands are sent to the socket and causes a back log which causes my
|> app to seemingly continuously call the file handler to process a command.
|> During this flood of commands the list widget is not updated although I
|> know I am making tk calls which insert entries. I have tried doing an
|> XFlush() call in my file handler after the Tcl_Eval() call, but this
|> has no effect. The updates finally reach the screen after the flood of
|> input subsides.

This is a feature of Tk:  all of the widgets intentionally delay updates
to themselves until the application gets caught up with incoming requests
of any type.  I consider this to be good in general, since it avoids
repeated redisplays in situations where the same widget is being modified
over and over.  The "update" command is provided for situations where you
want to force all the delayed redisplays to occur.  However, there's a bug
in the Tk 2.1 implementation of "update" where it looks for new requests
and processes them before doing delayed redisplays.  This means that
"update" in its current form won't do what you want, since you've got a
continual stream of new requests.  I've fixed the problem (by adding a
new option to "update") and the fix will appear in the next Tk release.