Re: [PATCH v7] Events when inferior is modified

[Doug Evans <dje@google.com>]

On Fri, Nov 7, 2014 at 4:21 AM, Pedro Alves <palves@redhat.com> wrote:
> On 11/06/2014 06:19 PM, Doug Evans wrote:
>> On Fri, Oct 24, 2014 at 8:13 AM, Pedro Alves <palves@redhat.com> wrote:
>>> On 10/17/2014 08:49 PM, Doug Evans wrote:
>>>> Alas our use of thread ids is a bit, umm, confusing
>>>> (in more ways than one! :-().
>>>> Here, it's not guaranteed that ptid.lwp has something useful,
>>>> and it may be that the target uses ptid.tid instead.
>>>>
>>>> See python/py-infthread.c:thpy_get_ptid.
>>>> I think we should make that non-static and use that here.
>>>> IOW, pass the whole ptid_t to the event.
>>>
>>> How about using GDB's own unique thread number instead of
>>> the ptid?  Doesn't seem to be any reason to expose
>>> target-side details or identifiers here?
>>
>> Yeah, I thought of that.
>> We already expose ptids.
>
> OOC, is that just py-infthread.c:thpy_get_ptid, or elsewhere
> too?
>
>> Plus one can look at them as just an id: something you receive, pass
>> around, and print.
>
> Yes, as long as we pass the whole ptid, that works.  Let's go with that.
>
>> But I don't have a strong preference, other than consistency.
>> Whatever we pick we need to use it for everything (barring compelling
>> reasons to do otherwise).
>>
>> Setting aside concerns of exposing target details,
>> are there other technical reasons to prefer one over the other?
>
> I'm been trying to come up with some rule, but it's very hard
> to say in general.  I was thinking that given that we're
> specifically referring to a user-visible thread, we should
> prefer the GDB number, like we generally expose GDB
> thread numbers to MI.  But maybe we'll find a case in the future
> where we do an infcall on some execution object that isn't mapped
> to a visible GDB thread, and so a ptid would work better.
>
>> Here's a question that comes to mind.
>> Internally we use ptids and not thread numbers.
>
> GDB didn't use to model non-threaded inferiors as single-threaded.
> Until pthreads or similar was detected as loaded in the inferior,
> "info threads" would came out empty.  So there's that historical part.
>
> (Related, I sometimes wonder about whether we should expose execution
> objects finer than "standard" threads, like fibers / lightweight execution
> agents (c++ N3874) / coroutines to the user as first class
> "GDB threads", if the runtime has those, thus think of "GDB threads"
> as the finer execution object type the user can interact with.
> Or maybe that's not the best model, and exposing "fibers"
> as first class citizens distinct from "threads" would be better.)
>
> On the target/backend/core run control side, we need to work
> with ptids, as we're interfacing with the lower debug APIs, which of
> course now nothing about GDB's thread ids, and sometimes need to
> interface with execution objects even if there's no GDB thread
> mapped to it, yet, or ever.
>
>> Do any of the reasons for doing so carry over to the Python API?
>
> I guess it depends on which level we're positioning the Python API.
> If at the same level as CLI/MI, and/or directly exposing
> the user-visible objects/concepts, then GDB ids seems preferable.
> Otherwise, if working at lower levels, a ptid may be better.
>
> Anyway.  To reiterate, I agree.  If we're just looking at
> the (whole) ptid as just an id: something you receive, pass around,
> and print, then it works for me.
>
>>
>> [While IWBN if internal and external APIs used the same id everywhere,
>> I'm more concerned with more technical details of picking one over the
>> other.  E.g., Thread IDs are more transient, they get recycled more
>> often, but technically ptids can get recycled too.]

One thing that occurs to me is that gdb can inform users when thread
ids get recycled, not so with ptids.  [An unlikely thing to need to
worry about in general, but I'm all for being robust where we can.]

Plus we can provide routines to map one to the other.
[Hmmm, if we give out thread ids, do we need to attach a "generation
number" or some such to them?]

So at the moment I guess I'm undecided.