From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21164 invoked by alias); 6 Nov 2014 18:19:31 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 21154 invoked by uid 89); 6 Nov 2014 18:19:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qg0-f45.google.com Received: from mail-qg0-f45.google.com (HELO mail-qg0-f45.google.com) (209.85.192.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 06 Nov 2014 18:19:30 +0000 Received: by mail-qg0-f45.google.com with SMTP id z107so1170577qgd.4 for ; Thu, 06 Nov 2014 10:19:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cxhDhYgCUtTpaBWYcuTJUUKUAq/OnhUye38i5704OAs=; b=Maz1sztLHgvAy97AfNoTYy8iK58BeeZrOjh1DKfv1Tf4uSHMIh8fflr+ubLHQ0BXtX M7YSvmLW1MYM2/jKWlPlN9GWrv6ZbpfBpFfSJ3bqbDIk1aTBjh2tkdCMNWofM4+aRr2q iaSSuwBmjmysUv+JA9YXQhgsZv3BgVB7YhCmkOKZcQ6MSRrS0RXiohmcY+Rr6mobt58+ G2huQXeSjj347T4sSo+Y8JGB1VbgyGgl/kMqzZkrVC+rir1LDVFHjwpxj5ZPYpK9BfFF 39SY4rD1vPHM8CoTdzLdeiDTIEN/FkTbXuq6Sd1dZ5fuzx9PbszDttUL+EqmCmDnD163 Ag/A== X-Gm-Message-State: ALoCoQmsZnlyVJQpTac/6JVQQHC57vgR5rbR5F5AMKSH636TqCCtlkA3m0CTZaU5xtS6L71NrBZa MIME-Version: 1.0 X-Received: by 10.224.11.137 with SMTP id t9mr6667979qat.10.1415297967849; Thu, 06 Nov 2014 10:19:27 -0800 (PST) Received: by 10.229.250.4 with HTTP; Thu, 6 Nov 2014 10:19:27 -0800 (PST) In-Reply-To: <544A6CB6.4080500@redhat.com> References: <5419C597.4000300@gmail.com> <542C3F4D.70104@redhat.com> <5441432B.5040103@gmail.com> <21569.29405.219428.940000@ruffy.mtv.corp.google.com> <544A6CB6.4080500@redhat.com> Date: Thu, 06 Nov 2014 18:19:00 -0000 Message-ID: Subject: Re: [PATCH v7] Events when inferior is modified From: Doug Evans To: Pedro Alves Cc: Nick Bull , gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg00120.txt.bz2 On Fri, Oct 24, 2014 at 8:13 AM, Pedro Alves 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.]