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

["Alain Magloire" <alain@xxxxxxx>]

> 
> Debug model implementors,
> 
> With the introduction of background jobs in the Eclispe 3.0 SDK, the debug 
> platform may now access a debug model API from multiple jobs at the same 
> time. For example, the debug view may be retrieving labels for stack 
> frames while the variables view is retrieving variables for a stack frame. 
> This may result in concurrent requests to a debug model API. Note that the 
> debug platform was not  built on the assumption that debug models require 
> serialized access.
> 
> In 3.1, we are extending the use of background jobs to retrieve content 
> for the debug view in the background as well. This is to avoid blocking 
> the UI while communicating with a remote debug target. This further adds 
> to the possibility of concurrent requests on a debug model API. (
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=44724)
> 
> As the job architecture is part for the Eclispe platform, it is 
> foreseeable that other clients may also use jobs to access APIs 
> concurrently - i.e. it may not be limited to the debug platform.
> 
> My question is, for how many debug models will this present a problem? Is 
> your debug model limited to serialized access, and if so, does it 
> serialize requests internally?
> 

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.

1)
  With CDT-2.x and above we try to encapsulate requests so that they can
be stand alone, for example asking for a variable value request maps to
x commands:

- save the context(thread/stackframe)
- select the context(thread/stackframe) of the variable
- restore the old context(thread/stackframe)

basically in gdb parlance:
(gdb) info threads # save context
(gdb) info stacks # save context
(gdb) thread xx
(gdb) frame yy
(gdb) print value
(gdb) frame x # restore context
(gdb) thread y # restore context

(and yes we make some optimization 8-)

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?