| [cdt-dev] RE: [cdt-debug-dev] CDI Update Stack Frame |
|
Doug, In our debugger we didn’t propagate the
suspend event in Eclipse until we got the stack frame changed event from our
back end and cached all stack frames. We had to introduce a little state machine
for that. Hated -> Stack List Ready -> Running. Also, in rare case when we wanted some
stuff updated while the target was suspended we were firing resume and then
immediately suspend. These two things worked for us on Eclipse
3.1 and 3.2. Again, we were implementing CDI interfaces.
Regards Dobrin From:
cdt-debug-dev-bounces@xxxxxxxxxxx [mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer Hey gang, I’m putting the claim that the CDI
can handle asynchronous calls to the test. For my Windows debugger integration, I have to
process all calls to the Windows API through a single thread. I have thus
created a command posting architecture (I guess it’s similar to the
CDI/MI interface). Now, when the framework calls any of the
getStackFrame* methods and I don’t have the current stack frame, I
dispatch a call to my thread and return 0/null. The hope is that when I do
finally get the stack frame I can dispatch an event of some sort to let the
framework know I have the stack information. I thought a changed event on the thread would do the
trick, but I see the implementation for handling the event is empty (and
besides, it didn’t work J).
Is there another way? Thanks, Doug Schaefer |