Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[dsdp-dd-dev] Re: [platform-debug-dev] FW: prototyping against flexible hierarchy API, notes

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).



Back to the top