Community
Participate
Working Groups
When using tcl debugger, since all the statements are evaluated in a slave interpreter, we encountered following "race condition". If a statement that was evaluated starts a regular timer and the callback for timer executes some statements in a namespace and calls "update" as well, the next statement evaluated in the debugger can execute in that namespace based on the timing and thus cause following three problems: 1. Variable conflicts because a statement to be stepped on like "set i 0" can overwrite the local variable of the timer callback. 2. Statement like "set i 0" can become a local variable in the timer callback and thus the main script to be debugged cannot access this variable. 3. Statement like "puts $i" cannot access "i" because it is executing in a completely different context.
Hi Pawan, Thank you for reporting this issue. At the moment DLTK don't have internal tcl debugger, it provides interface to the 3rd party (ActiveState) Tcl debugger engine. And this issue could be addressed only by the underlying debugging engine. Could you please report this issue to ActiveState? Based on the above I mark this issue as NOT_ECLIPSE here. Thank you, Alex
The same problem exists in the DLTK code which uses ConsoleProxy to get information from the tcl shell about variables. If anyone evaluates a timer script in the slave shell, whole infrastructure for getting information about variables etc... will break down. The fix is simple: DLTK needs to evaluate its commands in slave interpreter in a global namespace: DLTK's evaluate proc in the ConsoleProxy needs to be modified to: slave eval [list uplevel #0 $command]
