From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id EC4153858D20 for ; Mon, 15 Jan 2024 19:55:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EC4153858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org EC4153858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705348504; cv=none; b=mQOafMv4oJ7jgjsk1n9kIniMl9eb1g85FJk7ke+Tew+IXfTuvnA/J3hT5DK0vJ58HIWtFmpcUaQ5xxpr23xFZJy66XQ5dwpFOPc6u61GWy5gVGAnIvPajfazXQQs85zCxVW6UiL9iPtnDmrEVhfGkOF2OYOVDamnmp352CVof6U= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705348504; c=relaxed/simple; bh=jpCrDC+zfd7Mz4XhZanb8mpS4eVRSsufFjEeuYDrafI=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=t2/+OzeSqvMmul6tSV06USAdQIPKNRPHoysOmBIntGzp0btFTgjvC6P1n1oU/6DoKx33GJx4zCf/rQWOeZMul5eMBc44cTzgskpkiZs0SacG/hYhstJEss1417Q1yIBtnx9nqZCBQzyOhVj0RhMJbERAPavUs9XLX/6/1EUMGFQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1705348501; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zucmQ25BIyXtvMe/GqtxxcylQQVRmVIYoaHFDCE+LCg=; b=fh/cGot6rZWS9O6aM+XlHt7aXy6kWJKlhBJS1rwvK+5Xv91Al5pJOb8ZQwKv41qwAxeEmQ Wm3jt4z+OMNYnTpCB6oSH20OMTceTjjeLI/+3YW4Nx9fs/t0NMEjAW4CmLU7sHj6bYt7kd TOscFjckrUde3Ho1QKcMvZkFkrPdq4M= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-269-X2HE_lB6NXqSkOHOE1VNYQ-1; Mon, 15 Jan 2024 14:54:58 -0500 X-MC-Unique: X2HE_lB6NXqSkOHOE1VNYQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2EC888489E2; Mon, 15 Jan 2024 19:54:58 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.140]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DC5F13C25; Mon, 15 Jan 2024 19:54:56 +0000 (UTC) From: Florian Weimer To: Adhemerval Zanella Netto Cc: Trevor Gross , Trevor Gross via Libc-help , jistone@redhat.com, Carlos O'Donell Subject: Re: RFC: A way to get a TID from a pthread_t handler References: <87a5pbv9na.fsf@oldenburg.str.redhat.com> <41ebee39-2fe5-4ea0-ae6d-94321d2e59d0@linaro.org> Date: Mon, 15 Jan 2024 20:54:55 +0100 In-Reply-To: <41ebee39-2fe5-4ea0-ae6d-94321d2e59d0@linaro.org> (Adhemerval Zanella Netto's message of "Mon, 15 Jan 2024 16:47:25 -0300") Message-ID: <87le8q4bjk.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Adhemerval Zanella Netto: > Not really, mainly because I am not fully convinced that returning the > TID is really a good idea. It means that we will have two unique > identifiers for a pthread thread that might eventually get out of sync > (which would require us to add some support to return the correct value), > and it is API deviation that need some justification (since pthread was > defined as pthread_t being a opaque identifier). I think this point is largely moot because we already provide this information through pthread_getcpuclockid. Applications can call this function and reverse the encoding to get the TID. We might as well make this explicit, so that it's clearer that the application is asking for the TID. Thanks, Florian