[cdt-dev] multiple threads and call stack update

[Denis PILAT <denis.pilat@xxxxxx>]

I have an application that creates around 100 threads.
On Eclipse 3.3, after a stepping operation, an update of the call stack 
is requested by Eclipse to the debugger for some of these threads.

After the program stops, you can see with the verbose console mode 
something like:
[1,200,399,158,705] 649-thread-select 3
[1,200,399,158,732] 650-stack-list-frames 0 8
[1,200,399,159,169] 651-stack-list-frames 0 8
[1,200,399,159,181] 652-thread-select 103
[1,200,399,159,209] 653-thread-select 2
[1,200,399,159,235] 654-stack-info-depth
[1,200,399,159,329] 655-stack-info-depth
[1,200,399,159,330] 656-thread-select 103
[1,200,399,159,345] 657-thread-select 2
[1,200,399,159,371] 658-stack-list-frames 0 5
[1,200,399,159,480] 659-thread-select 103
[1,200,399,159,508] 660-thread-select 1
[1,200,399,159,532] 661-stack-info-depth
[1,200,399,159,536] 662-stack-info-depth
[1,200,399,159,538] 663-thread-select 103
[1,200,399,159,551] 664-thread-select 1
[1,200,399,159,574] 665-stack-list-frames 0 2
...etc...


On Eclipse 3.2 only the current thread requested a call stack frame. 
Other thread requested an update only if they are selected in the debug 
view, and as threads in the debug view are all collapsed at each step 
(like in the 3.3 version),  that was much more optimized in term of 
number of requests done to the debugger.


Is the 3.3 behaviour a normal behaviour or a regression ?
I'm wondering why Eclipse requests call stack frame  for threads that 
are not expanded in the debug view ?
And why it requests that only for parts of the threads ?


Thanks for you answer
Denis PILAT / STMicroelectronics