Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-debug-dev] Debug Model Poll - Serialized vs. Concurrent 
Alan Boxall wrote:
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.
This is what our debugger implementation does (Wind River). And yes it does cause problems with changed variable highlighting, but that's a small price to pay for the increased performance. Unfortunately we had to write our own locals (and other variables) views for this, because the SWT tree widget does not support lazy loading of values (i.e. refreshing only the labels that are visible on the screen.) 

- Pawel
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

Back to the top