From: SourceForge.net <no...@so...> - 2005-01-31 21:00:43
|
Bugs item #1113452, was opened at 2005-01-31 13:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1113452&group_id=10894 Category: 02. Event Loops Group: current: 8.4.9 Status: Open Resolution: None Priority: 5 Submitted By: kodecharlie (kodecharlie) Assigned to: Jan Nijtmans (nijtmans) Summary: Tk_MainLoop processes WM_DEVICE_CHANGE infinitely often. Initial Comment: Here is what happens: 0. In MacroMedia's Director MX 2004, I launch a thread (via _beginthread, called from an xtra) that starts a Tcl interpreter (with Tk, TclX et al built in). 1. The Task Manager in Windows XP shows that CPU consumption rises to 50-60%. (Note that if I use the same Tcl/Tk libraries outside of the context of a Director xtra, no such penalty occurs.) 2. I then load the xtra and debugged version of Tcl/Tk 8.4.9 into VC++. I set breakpoints at Tk_MainLoop, Tcl_DoOneEvent, and Tcl_WaitForEvent. 3. What I observe is that after initialization, the Tcl thread essentially goes into a polling mode in which it tries to process a WM_DEVICE_CHANGE (0x0219) message. The sequence of steps is this (Note that all messaging here is done on the thread; ie, no window is involved.): * Tcl_DoOneEvent is called. * Tcl_WaitForEvent is called. * PeekMessage is called and finds a WM_DEVICE_CHANGE with the wParam set to DBT_DEVNODES_CHANGED (0x0007). * GetMessage is called and finds the WM_DEVICE_CHANGE msg. * TranslateMessage is called and posts back the WM_DEVICE_CHANGE msg to the messaging queue for the thread. * DispatchMessage is called with the WM_DEVICE_CHANGE msg. At this point, program execution goes back to Tk_MainLoop, and then Tcl_DoOneEvent is called and the whole sequence of steps continues ad infinitum. NOTE: I have observed this same behavior for an undefined message with ID 0x0118. To correct this infinite message-processing loop, I inserted the following code in tcl8.4.9/win/tclWinNotify.c: result = GetMessage(&msg, NULL, 0, 0); while (msg.message == WM_DEVICECHANGE || msg.message == 0x0118) { result = GetMessage(&msg, NULL, 0, 0); } This "worked", in the sense that said inifinite processing loop no longer occurs. Although I'm not sure, I believe that launching a Tcl thread in this manner triggers the WM_DEVICE_CHANGE message, and that the Tcl_DoOneEvent processing logic just doesn't handle this case gracefully. IE, things "still work", but you sacrifice a huge amount of CPU horsepower in the process. kodeCharlie ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1113452&group_id=10894 |
From: SourceForge.net <no...@so...> - 2005-02-02 05:33:24
|
Bugs item #1113452, was opened at 2005-01-31 13:00 Message generated for change (Comment added) made by hobbs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1113452&group_id=10894 Category: 02. Event Loops Group: current: 8.4.9 Status: Open Resolution: None Priority: 5 Submitted By: kodecharlie (kodecharlie) Assigned to: Jan Nijtmans (nijtmans) Summary: Tk_MainLoop processes WM_DEVICE_CHANGE infinitely often. Initial Comment: Here is what happens: 0. In MacroMedia's Director MX 2004, I launch a thread (via _beginthread, called from an xtra) that starts a Tcl interpreter (with Tk, TclX et al built in). 1. The Task Manager in Windows XP shows that CPU consumption rises to 50-60%. (Note that if I use the same Tcl/Tk libraries outside of the context of a Director xtra, no such penalty occurs.) 2. I then load the xtra and debugged version of Tcl/Tk 8.4.9 into VC++. I set breakpoints at Tk_MainLoop, Tcl_DoOneEvent, and Tcl_WaitForEvent. 3. What I observe is that after initialization, the Tcl thread essentially goes into a polling mode in which it tries to process a WM_DEVICE_CHANGE (0x0219) message. The sequence of steps is this (Note that all messaging here is done on the thread; ie, no window is involved.): * Tcl_DoOneEvent is called. * Tcl_WaitForEvent is called. * PeekMessage is called and finds a WM_DEVICE_CHANGE with the wParam set to DBT_DEVNODES_CHANGED (0x0007). * GetMessage is called and finds the WM_DEVICE_CHANGE msg. * TranslateMessage is called and posts back the WM_DEVICE_CHANGE msg to the messaging queue for the thread. * DispatchMessage is called with the WM_DEVICE_CHANGE msg. At this point, program execution goes back to Tk_MainLoop, and then Tcl_DoOneEvent is called and the whole sequence of steps continues ad infinitum. NOTE: I have observed this same behavior for an undefined message with ID 0x0118. To correct this infinite message-processing loop, I inserted the following code in tcl8.4.9/win/tclWinNotify.c: result = GetMessage(&msg, NULL, 0, 0); while (msg.message == WM_DEVICECHANGE || msg.message == 0x0118) { result = GetMessage(&msg, NULL, 0, 0); } This "worked", in the sense that said inifinite processing loop no longer occurs. Although I'm not sure, I believe that launching a Tcl thread in this manner triggers the WM_DEVICE_CHANGE message, and that the Tcl_DoOneEvent processing logic just doesn't handle this case gracefully. IE, things "still work", but you sacrifice a huge amount of CPU horsepower in the process. kodeCharlie ---------------------------------------------------------------------- >Comment By: Jeffrey Hobbs (hobbs) Date: 2005-02-01 21:33 Message: Logged In: YES user_id=72656 Not enough information is given in the above trace. The TranslateMessage and DispatchMessage must somehow be getting into Tk, which isn't returning an expected error code. Otherwise, why does it come back to Tcl unless we are receiving multiple such messages? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1113452&group_id=10894 |
From: SourceForge.net <no...@so...> - 2005-02-02 09:42:58
|
Bugs item #1113452, was opened at 2005-01-31 13:00 Message generated for change (Comment added) made by davygrvy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1113452&group_id=10894 Category: 02. Event Loops Group: current: 8.4.9 Status: Open Resolution: None Priority: 5 Submitted By: kodecharlie (kodecharlie) Assigned to: Jan Nijtmans (nijtmans) Summary: Tk_MainLoop processes WM_DEVICE_CHANGE infinitely often. Initial Comment: Here is what happens: 0. In MacroMedia's Director MX 2004, I launch a thread (via _beginthread, called from an xtra) that starts a Tcl interpreter (with Tk, TclX et al built in). 1. The Task Manager in Windows XP shows that CPU consumption rises to 50-60%. (Note that if I use the same Tcl/Tk libraries outside of the context of a Director xtra, no such penalty occurs.) 2. I then load the xtra and debugged version of Tcl/Tk 8.4.9 into VC++. I set breakpoints at Tk_MainLoop, Tcl_DoOneEvent, and Tcl_WaitForEvent. 3. What I observe is that after initialization, the Tcl thread essentially goes into a polling mode in which it tries to process a WM_DEVICE_CHANGE (0x0219) message. The sequence of steps is this (Note that all messaging here is done on the thread; ie, no window is involved.): * Tcl_DoOneEvent is called. * Tcl_WaitForEvent is called. * PeekMessage is called and finds a WM_DEVICE_CHANGE with the wParam set to DBT_DEVNODES_CHANGED (0x0007). * GetMessage is called and finds the WM_DEVICE_CHANGE msg. * TranslateMessage is called and posts back the WM_DEVICE_CHANGE msg to the messaging queue for the thread. * DispatchMessage is called with the WM_DEVICE_CHANGE msg. At this point, program execution goes back to Tk_MainLoop, and then Tcl_DoOneEvent is called and the whole sequence of steps continues ad infinitum. NOTE: I have observed this same behavior for an undefined message with ID 0x0118. To correct this infinite message-processing loop, I inserted the following code in tcl8.4.9/win/tclWinNotify.c: result = GetMessage(&msg, NULL, 0, 0); while (msg.message == WM_DEVICECHANGE || msg.message == 0x0118) { result = GetMessage(&msg, NULL, 0, 0); } This "worked", in the sense that said inifinite processing loop no longer occurs. Although I'm not sure, I believe that launching a Tcl thread in this manner triggers the WM_DEVICE_CHANGE message, and that the Tcl_DoOneEvent processing logic just doesn't handle this case gracefully. IE, things "still work", but you sacrifice a huge amount of CPU horsepower in the process. kodeCharlie ---------------------------------------------------------------------- >Comment By: David Gravereaux (davygrvy) Date: 2005-02-02 01:42 Message: Logged In: YES user_id=7549 Maybe a window within the thread that is owned by macromedia is the one reposting? ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2005-02-01 21:33 Message: Logged In: YES user_id=72656 Not enough information is given in the above trace. The TranslateMessage and DispatchMessage must somehow be getting into Tk, which isn't returning an expected error code. Otherwise, why does it come back to Tcl unless we are receiving multiple such messages? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1113452&group_id=10894 |