Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-debug-dev] Changes/exploration to the CDI interface 
Bonjour,
  This is an excerpt from an email exchange with Mikhail that we think would
be more beneficial in the mailing list;


> The "workarounds" I mentioned are not hacks or real workarounds. 

> For example, there is ICDIThreadGroup interface that in fact groups all 
> thread related functionality (getThreads, getCurrentThread). I use it 
> instead of ICDITarget in the content adapter to get threads.
>

Right, the ICDIThreadGroup was to group thread and allow "atomic" actions on
them.  For example, if you have a set of threads in a thread group you could
do next, step, etc ... on the set.  This was interesting for debuggers or
frameworks that supporting "lock steps".  Another example is distributed
systems where the session encapsulates multiple debuggers, then we could
create an new thread group with different threads from different
debuggers/target and make them step in lock.  Unfortunately not many
debugger frameworks support this.
 
> Roughly, I replace (element instanceof ICDITarget) by (element 
> instanceof ICDIThreadGroup). In this case any object that implements 
> ICDIThreadGroup will have threads as children.
>

Good!!
ICDIThreadGroup and ICDITarget are different although a target in the CDI
model can be seen as a grouping of thread, but that is just a side effect.


> The ICDIThreadGroup is in place, but for stack frames I need to group 
> the stack frame related functionality under ICDIStack interface.

Grouping of stackframe was not done because we thought it was overkill and
more simply there was no practical need for it.  The only nitpicking is the
name the interface; ICDIStackGroup or ICDIStackframeGroup to be consistent.
So were can one get a stack frame group?

public interface ICDIThread extends ...., ICDIObject {

	/**
	 * @deprecated use getStackFrameGroups()
	 */
	ICDIStackFrame[] getStackFrames() throws CDIException;

	/**
	 * @deprecated use ICDIStackFrameGroup.getStackFrames(fromIndex,
len)
	 */
	ICDIStackFrame[] getStackFrames(int fromIndex, int len) throws
CDIException;


	/**
	 * New interface
	 */
	ICDIStackFrameGroup[] getStackFrameGroups() throws CDIException;
	
}

public interface ICDIStackFrameGroup extends ICDIExecuteStepReturn,
ICDIObject {

	ICDIStackFrame[] getStackFrames() throws CDIException;

	ICDIStackFrame[] getStackFrames(int fromIndex, len) throws
CDIException;
}


So why to you need to group stackframes?  I thought you had a limit to deal
with deep level stacks or deep recursions?

> Same 
> is for terminate and disconnect related functionality. This is an 
> extension of CDI, but it is not going to affect any implementation at
all.
> In addition all CDI object implementations have to extend 
> PLatformObject, it is not necessary to add IAdaptable to CDI.
>

Sounds good, but then the interface now carries Eclipse interfaces.  Before
it was stand-alone, making the change breaks the rule.

public interface ICDIObject extends org.eclipse.core.runtime.IAdaptable {
}

What are the advantages? Any other ways?

Back to the top