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

[Alan Boxall <boxall@xxxxxxxxxx>]

The PDT plugin requires serialized access
to the many (8+) debug engines that it connects to.     

But I have a further problem in that
requests are not queued but will be rejected if 
the debug engine connection is busy
with an existing request.    This surfaced when stackframe labels

were retrieved on another thread.  
 The labels would appear as <null> because the request was rejected
not just
queued.

I wonder if the real underlying performance
problems will be masked by switching to background threads/jobs.

It if really takes a long time to get
a large number of local variables then pushing it to a background job might
make the UI responsive before the list
is retrieved, but as most engines have indicated the requests are still
serialized and have to complete before
the next one can be sent.    
If the request to get the locals can't
be cancelled (I know I can't cancel a request once it has been
sent to the debug engine without terminating
the session) then it will mean that the locals won't be populated 
in a timely manner and it could stop
the user from stepping or doing anything else with the debuggee until that
original long running request has completed.

Perhaps the UI could add to certain
requests the max number of entries required.    e.g. when asking
for locals it 
could request the number that would
fit in the view.    The engine could use this instead of getting
them all as it does today.
I deal with some COBOL applications
that can have 10,000 (yes that is correct) "local variables".
  Today we have told customers
to close the Variables view.
If the user scrolls then the next chunk
of variables could be requested.    Assuming engines could deal
with this the 
UI would become more responsive and
possibly more consistent (programs locals no longer slow down stepping
as their number
increases)
A possible variation is asking for the
list of variables but don't get their values until they are displayed.
   I know that this 
would cause problems with showing changed
variables but I am sure many would trade off faster stepping for that feature.

I have already opened a feature to cap
the number of stackframes requested to both improve stepping and UI clutter.
This might be another candidate.

Alan Boxall - IBM Distributed Debugger

platform-debug-dev-admin@xxxxxxxxxxx wrote on 11/23/2004
03:32:27 PM:

> 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?
> 
> Thanks,
> 
> Darin
> _______________________________________________
> platform-debug-dev mailing list
> platform-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-debug-dev