Re: [PATCH v7] Events when inferior is modified

[Pedro Alves <palves@redhat.com>]

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

Thanks,
Pedro Alves