Re: [PATCH v7] Events when inferior is modified

[Doug Evans <dje@google.com>]

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.
Plus one can look at them as just an id: something you receive, pass
around, and print.
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?
Here's a question that comes to mind.
Internally we use ptids and not thread numbers.
Do any of the reasons for doing so carry over to the Python API?

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