[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-debug-dev] querying the "active" CDI thread
|
John,
Usually when I've wanted to know the thread UI context it's because I'm
calling the debugger backend from our CDI plugin and I need to give it a
thread or stack frame context to work with and I don't have one at that
point. I think the right solution to this is to revise the CDI API to pass
in the best known debug context, there are a couple places where this
information gets "dropped" as code filters down through the API layers.
I'll contact you off-line to give you more details and then we can propose
some changes to Mikhail.
- Ken
> From: John Cortell <john.cortell@xxxxxxxxxxxxx>
> Reply-To: CDT Debug developers list <cdt-debug-dev@xxxxxxxxxxx>
> Date: Fri, 09 Dec 2005 16:01:46 -0600
> To: CDT Debug developers list <cdt-debug-dev@xxxxxxxxxxx>
> Subject: Re: [cdt-debug-dev] querying the "active" CDI thread
>
> OK. Well, I'll shelve this for now. If it turns out the lack of the
> active thread context in our expression parser is overly problematic,
> I'll look to see what API recommendations I can make that would help us.
>
> John
>
> At 03:57 PM 12/9/2005, Mikhail Khodjaiants wrote:
>> 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
>>
>> _______________________________________________
>> 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
