[dsdp-dd-dev] Re: [platform-debug-dev] FW: prototyping against flexible

[Darin Wright <Darin_Wright@xxxxxxxxxx>]

Sorry Pawel, I forgot to comment on this one...

> 
> When it comes to having action adapters vs. interfaces, it's more
a 
> question of efficiency in updating the action state more than anything
> else.  I think I need to explain a little more on how we implement
these
> 
> interfaces:
> 
> The the "model context" objects that are returned by the
content 
> provider are immutable tokens which are used as input to various methods
> 
> in the connection layer 
> (canResume/Resume/canSuspend/Suspend/canTerminate/Terminate/etc.).
 But 
> the connection layer operates on the single dispatch loop, so whenever
a
> 
> synchronous data request is made, such as canResume(), the calling
> thread is blocked while the request is evaluated on the dispatch 
> thread.  I noticed that when a selection is made in Debug view,
multiple
> 
> jobs are started (one for each action), all which just end up being
> blocked waiting for the single thread to service the requests on the
> single dispatch thread.  Some actions (e.g. resume), call the
> canResume() multiple times, invoking a separate dispatch each time.
> 
> With retargetable actions, I was hoping that we could handle these
> updates the way we handle view updates with flexible hierarchy 
> interfaces.  Then we wouldn't need a separate job to be started
for each
> 
> action on each state update, and if multiple tests needed to be 
> performed, they could all be done in a single dispatch.

You are right. The "canDoSomething" interfaces
are synchronous and should be made asynchronous. We don't have the cylces
for this in M5 - I will file an enhancement request for this. The API freeze
is M5 - however, since our "flexible platform API" is provisional
and internal, we can hopefully do something about this for 3.2.

> >
> > >     * Editor positioning and annotation logic
is written around the
> > >       IStackFrame interface, so I appreciate
the
> ISourceDisplayAdapter
> > >       interface, I just wish that there was
an official way to
> access
> > >       the standard debugger images.  BTW,
ISourceDisplayAdapter is
> not
> > >       currently accessible because of restriction
on
> > >       org.eclipse.debug.internal.ui.contexts.provisional
package.
> >
> > Right, our standard "source display adapter" is based
on stack frames.
> 
> > We've added IInstructionPointerPresentation in 3.2 (enhanced
for M5), 
> > but it is intended to be used with the "standard model".
Are you just 
> > looking for public image access - currently the instruction pointer
> > images are internal, but could be made public (there Ids are
in 
> > IInternalDebugUIConstants - IMG_OBJS_INSTRUCTION_POINTER and
> > IMG_OBJS_INSTRUCTION_POINTER_TOP. If you can envision helpful
API 
> > here, please file enhancement requests. (Note, at this time we're
> > under the gun to freeze public API (Friday Feb 10), in preparation
for
> 
> > M5).
> >
> This is not a bid deal, since it's not hard to copy an icon, but for
> long term maintenance I think it would make sense to put 
> IInternalDebugUIConstants and DebugPluginImages in a public package.
 
> I'll file a bug on it for, but if you decide against it that's fine
too.

We can move the image constants to API. There is already
an accessor to get images from DebugUITools.getImage/ImageDescriptor(key).

Thanks,

Darin