Tcl/tk generating too many wiindow manager events
Jonathan Hayward
), and on some platforms at least (e.g. 32 bit 2.6.24-gentoo-r8
running KDE), other program's windows continue to update but the
window manager appears to be swamped: mouse moves and alt-tabs appear
to do nothing, at least nothing until a couple of minutes after
tkbiff's wish process has been killed.
In trying to track down the problem, I placed logging statements at
the beginning of each function call or loop; I received less than 200
logging statements before it swamped the window manager. Once it got
swamped, there were no further logging statements output, even though
the swamped computer displayed other programs' windows while it seemed
to stop responding to mouse movements, alt-tabs, etc.
I couldn't find documentation for traps that could get Tk to swamp the
window manager... any warnings or suggestions I can use to find out
what is swamping the window manager?
--
-- Jonathan Hayward, christos.jon...@gmail.com
** To see an award-winning website with stories, essays, artwork,
** games, and a four-dimensional maze, why not visit my home page?
** All of this is waiting for you at http://JonathansCorner.com
++ Would you like to curl up with one of my hardcover books?
++ You can now get my books from http://CJSHayward.com
Gerald W. Lester
--
+------------------------------------------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Alexandre Ferrieux
<christos.jonathan.hayw...@gmail.com> wrote:
>
> I couldn't find documentation for traps that could get Tk to swamp the
> window manager... any warnings or suggestions I can use to find out
> what is swamping the window manager?
First, I'd try to use the OS to home in on the problem: use
"top" (hopefully in an xterm started before, or in an ssh session) to
know whether the wm process is consuming a lot of CPU. Also, use
"strace" to attach to it and see what syscalls it makes when it goes
berzerk.
Second, I'd try to investigate at the level of the X protocol. To do
this, start your offending Tcl app from another machine on the LAN,
with $DISPLAY directed to the machine-with-a-sensitive-wm (use 'xhost
+' if needed). Then use tcpdump/tshark/wireshark on TCP port 6000 and
decode the X packets before and during the wild loop.
Doing this will probably give you the solution; however if you have
problems with one of these steps, please say so.
-Alex
Jonathan Hayward
> Do you happen to have a master with both grid and pack managing its slaves?
>
>
>
> Jonathan Hayward wrote:
> > ), and on some platforms at least (e.g. 32 bit 2.6.24-gentoo-r8
> > running KDE), other program's windows continue to update but the
> > window manager appears to be swamped: mouse moves and alt-tabs appear
> > to do nothing, at least nothing until a couple of minutes after
> > tkbiff's wish process has been killed.
>
> > In trying to track down the problem, I placed logging statements at
> > the beginning of each function call or loop; I received less than 200
> > logging statements before it swamped the window manager. Once it got
> > swamped, there were no further logging statements output, even though
> > the swamped computer displayed other programs' windows while it seemed
> > to stop responding to mouse movements, alt-tabs, etc.
>
> > I couldn't find documentation for traps that could get Tk to swamp the
> > window manager... any warnings or suggestions I can use to find out
> > what is swamping the window manager?
>
> > --
>
> > ** To see an award-winning website with stories, essays, artwork,
> > ** games, and a four-dimensional maze, why not visit my home page?
>
> > ++ Would you like to curl up with one of my hardcover books?
>
> --
> +------------------------------------------------------------------------+
> | Gerald W. Lester |
> |"The man who fights for his ideals is the man who is alive." - Cervantes|
> +------------------------------------------------------------------------+
Yes. Commenting out "pack" lines seemed to fix the locked WM.
Thanks for just the kind of response I needed...
Jonathan Hayward
wrote:
Thank you for a good, in-depth answer!