Re: [platform-debug-dev] Debug Model Poll - Serialized vs. Concurrent

["Alain Magloire" <alain@xxxxxxx>]

> 
> > 
> > If we take the case of the CDT using GDB as the backend.  The requests
> > are internally serialize i.e. pipeline to gdb.  Even if the clients ask
> > the commands in a concurrent fashion.
> 
> This is good.
> 
> > 
> > But ... a few problems, that we've see with Eclipse-3.0.x
> > 
> > case a) wrong context:
> >   Target is supended, 2 jobs are queued, one of the job, say job #1,
> > do "stepOver", by the time
> > job #2 executes, we already hit a breakpoint, so job #2 will be 
> > evaluated in the wrong context.
> > 
> > case b) Too much jobs:
> >   Target is suspended, xxx number of jobs are pending,  job #2 do 
> > "stepOver", the rest (xxx - 2) jobs
> > will all fail one by one, or see case (a) when the target changes 
> > state to be suspended.
> > Maybe it would be better to have some cancellation scheme ?
> > 
> > In brief are you planning some job control?
> > 
> 
> We should be able to provide some help here. For example, if a job is 
> retrieving variables for a stack frame, and then a step is started, the 
> job retrieving variables should be cancelled.
> 

Fantastic!

Making sure we are on the same wavelength:
 Not all debug model can run threads separately, meaning running x threads while the others remain suspended.
 For the majority of C/C++ debug model, including GDB:
  - suspending a thread is suspending __all threads__.
  - running(step) a thread is running __all threads__.
 So jobs may have to check the state of the thread they are querying not only the one where the step was issued.

Maybe a configuration on the DebugTarget that indicates the thread model so to let the
Eclipse debug framework do whatever optimization.