[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-debug-dev] querying the "active" CDI thread
|
Sorry, but I really don't like this approach. We used to synchronize
"active" and "current" threads and it didn't work well for many reasons.
As far as I understand your parser needs more information than we currently
provide by CDI calls. What if we just change or add a new API?
----- Original Message -----
From: "John Cortell" <john.cortell@xxxxxxxxxxxxx>
To: "CDT Debug developers list" <cdt-debug-dev@xxxxxxxxxxx>; "CDT Debug
developers list" <cdt-debug-dev@xxxxxxxxxxx>
Sent: Friday, December 09, 2005 4:15 PM
Subject: Re: [cdt-debug-dev] querying the "active" CDI thread
Hm. I see your point. The CDT core plugin is not UI aware, and it's
that plugin which provides CDI.
OK. How about a slightly different approach. Does CDT UI get notified
when the active thread selection changes? (I figure it must) If so,
it could drive a notification through the CDT core plugin and into
the CDI plugin, providing, of course, the ICDIThread. The CDI plugin
could then maintain its own "active thread" state, which, assuming no
notifications fall through the cracks, should be in synch with that
of the platform.
If that's not feasible, I'll give up and see what other solution I
can come up with. The reason I need it is difficult to explain. I
know that it probably smells of poor design, but it has to do with
how our debugger engine's expression parser works. It's a long story
and I'm sure if I explained it, you'd be sorry you asked :-) It's not
the end of the world if we can't get the active ICDIThread; it merely
provides the potential for a better expression resolution in some cases.
Anyway, I'll drop it if my latest suggestion doesn't pan out. Thanks
for the insight.
John
At 02:43 PM 12/9/2005, Mikhail Khodjaiants wrote:
The problem is that CDI is not aware of the workbench and UI
components. This means the "active thread" notion can not be defined
in terms of CDI.
The DebugUITools class belongs to the DebugUI plugin and it can not
be used in the core plugins. So if you need to do something with the
current context you have to do it in a UI plugin.
Can I ask you why do you need it? Maybe we can come up with a better
solution.
----- Original Message ----- From: "John Cortell"
<john.cortell@xxxxxxxxxxxxx>
To: "CDT Debug developers list" <cdt-debug-dev@xxxxxxxxxxx>
Sent: Friday, December 09, 2005 3:24 PM
Subject: Re: [cdt-debug-dev] querying the "active" CDI thread
The "active thread" I'm referring to is the thread that's selected in
the Debug view. You've enlightened me on how I could get the IThread
for it. However, I need the ICDIThread associated with it (if such an
association exists for that particular thread). You suggested you
might be able to provide a way to map the IThread to its ICDIThread.
I'm saying that would do the trick, but that I suspect that would
open a door we don't want to open (give CDI plugins the ability to
map between CDI and platform objects).
The ideal solution for me would be to have CDT provide a CDI function
which retrieves the "active thread" (as per my definition above) as
an ICDIThread. The implementation of this function in CDT would get
the active IThread in the way you described earlier, then do the
mapping and give me (the caller) the corresponding ICDIThread.
A gdb notion of the "current thread" is not part of this discussion.
John
At 02:02 PM 12/9/2005, Mikhail Khodjaiants wrote:
John,
Maybe, I don't understand your question. What does the "active
thread" mean in terms of CDI?
There is a thread selected in UI and some backends use the "current
thread" notion. But there is no relation between these two. For
example, selecting a thread in the Debug view doesn't make this
thread "current" in gdb.
If you provide a conversion mechanism for threads, then you'll be
somewhat obligated to do the same for other types of object
(variables, processes, etc). That means you'll be exposing platform
objects to CDI plugins. I have a feeling that's not a good thing. It
could pave the way for hybrid-type plugins--CDI backend that deals
with CDI objects and platform ones at the same time. That could get
ugly, I imagine.
I agree with this and that's why there is no public access to the
underlying CDI objects. I would rather leave it as a last resort.
Mikhail
----- Original Message ----- From: "John Cortell"
<john.cortell@xxxxxxxxxxxxx>
To: "CDT Debug developers list" <cdt-debug-dev@xxxxxxxxxxx>
Sent: Friday, December 09, 2005 2:05 PM
Subject: Re: [cdt-debug-dev] querying the "active" CDI thread
Rather than provide a conversion mechanism to go from a platform
object (IThread) to its associated CDI one (ICDIThread), could CDI
not provide an operation that simply gets that active thread as an
ICDIThread? Thing is, I'm not looking to open up a can of worms. If
you provide a conversion mechanism for threads, then you'll be
somewhat obligated to do the same for other types of object
(variables, processes, etc). That means you'll be exposing platform
objects to CDI plugins. I have a feeling that's not a good thing. It
could pave the way for hybrid-type plugins--CDI backend that deals
with CDI objects and platform ones at the same time. That could get
ugly, I imagine.
I didn't want to turn my request into that. But if you think that's
the best approach for this particular issue...
John
At 11:19 AM 12/9/2005, Mikhail Khodjaiants wrote:
In Eclipse 3.1 you can get the current context by calling the
static
"getDebugContext" method of DebugUITools which returns IAdaptable.
You can get an IThread object if the current context is IStackFrame
or IThread. So it comes back to the question: can we access the
underlying CDI thread object from an instance of IThread? There is
no direct access to it right now, but I'll try to figure out if it
is posible or not.
----- Original Message ----- From: "John Cortell"
<john.cortell@xxxxxxxxxxxxx>
To: "CDT Debug developers list" <cdt-debug-dev@xxxxxxxxxxx>
Sent: Friday, December 09, 2005 11:50 AM
Subject: Re: [cdt-debug-dev] querying the "active" CDI thread
Not really. Let see if I can explain this better.
The Debug view provides a thread context, right? The notion of the
"active thread" (my words). Visually, this is the thread that is
selected in the view. That thread should provide the context for
the
Variables and source views, for example. This is my understanding;
perhaps it's incomplete or flat out incorrect, but that's what I'm
basing my question on.
I'm trying to find out if I can get the CDI object corresponding
to
that thread in a global way. I suppose I could look at how some
CDT
views work, if indeed there are any that work off the active
thread
context. But I'm assuming that context is passed to the view from
the
platform--a top down approach. I'm looking at it from the
perspective
of isolated code. In some code in my plugin, I want to access the
CDI
thread for the active thread in the Debug view. This is a global
state, so there should be a global way to access it.
Does that make any more sense?
John
At 10:25 AM 12/9/2005, Mikhail Khodjaiants wrote:
John,
Do you want to access to the underlying CDI thread object from an
instance of IThread? Is this what you mean?
Mikhail
----- Original Message ----- From: "John Cortell"
<john.cortell@xxxxxxxxxxxxx>
To: "CDT Debug developers list" <cdt-debug-dev@xxxxxxxxxxx>
Sent: Friday, December 09, 2005 7:05 AM
Subject: [cdt-debug-dev] querying the "active" CDI thread
From within a CDI-extension plugin, is there a global way to
query
the
CDI
thread object associated with the "active" thread, as per the
selection
in
the Debug view?
John
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
