From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id 64B623858410 for ; Mon, 15 Jan 2024 19:47:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 64B623858410 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 64B623858410 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::634 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705348052; cv=none; b=EnQOTrYLaSTRMIcuDndvtUluLO8pA3JqjsnY3mBsgFhaKZWwt9RY8AwUdVijf91kLrc+WK+lmWkR0uUG8yY6Zyj4wuf0489MVX/XK7YMduLRTVMadEDcHM5MJD21NQiS/nCjhxokRycLx/CZd8Rq1+JWOOxo0eUorICfH5gzFzc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705348052; c=relaxed/simple; bh=dYc2FMZ2L7gdaG7VyHdVyHW+4Gi+qJcSHfpMpdSyBeM=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=C5Ge8yEYg6NN7xkVvjzZyQaE/slfnSLN1dbe1pvmiQVZMJppsBUMBxrdic2UoOvuBVVMcXctZMa3lRHDX7cfeAIe+o/DteVwvhSXgczzK90WoyUHoXZy+mZTOPW74m/AOajGm/ZwJ9tETdaIARNiDbFFSUtydMbrlGG8ASF2aw8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-1d5dcd5a5bdso1589005ad.1 for ; Mon, 15 Jan 2024 11:47:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1705348049; x=1705952849; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=KKQyRVL7HHbSwFa96epYTWR7usnwhahptEP4eKpM1eQ=; b=LjrslPYdSEJEQnJFGFj+h/kZGgaHD8xBi/h42bdxGC/2fQRew8Mo5YnnLUVSpOUe8y 9/nq5Skk6loj5lmt75USN6zYM7NPM1ImpCVh3EiRIZsFwc+bB998/LBq05HFf9R1Yl0m RIfa7yhhYnuyNJeCKfv9qcTJ/v+bHPzGbKDLGStYmiJ2e9RUynRTOV6jM2TAcmm3Ppn/ TnkA4M6yyd5zWX8701DjuUfvw2Ykm+l+l5cUSJru3pPpc7dYHInduxM5ewpYQ1GM0/5p i2FLFnJjpx1JhEQNTITqau6G/wtTXp3cHHOYTpRB1bhRn/yniP9y8/ou2HfVfemI1+nm idDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705348049; x=1705952849; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KKQyRVL7HHbSwFa96epYTWR7usnwhahptEP4eKpM1eQ=; b=poQcyFriCl8vAgrKWH8sSkc1zzpq5CUrPBDA5nQUbRXX8KcjAwTpNqsYHHQaO1BD3h FZawog4EsGdF7RD1G1sWgaJ8MzYlpO++LkFrk7h/qCkMfcZF+GVvghcsynnWFYn6252F KrzixbJHt8BWXdQNSV2kd6w/Mt4+M9M9oD0ULusijewNA6IxxHfRYjHezJOAv2xk/lfA TfxXTCiX3Ph2NYvpb5I23dbdExjQ+Yj4yYCRhOYrHry494r4JVfmcZBI4bGA2zX6YxVy AlUXRWbIERo1CC8MDnPjRqcFB0PcvUB38YvXAI5ujstZu18TEFap7SHFVEyZUSlguNBl jwUg== X-Gm-Message-State: AOJu0YzkTg29n7K+l0xKYjbHxXLkiDCK2UAMnBra5fx7aQAP9lHOSs1p zg6nxy70BJntW05efFk8hRTCBv6JkxDggd8T4VoDXUEXnIg= X-Google-Smtp-Source: AGHT+IF+on5GjEjFmn/2KEDXFeZXZ2dRJLNwtHBD9vRPVkmN3LSKlpbBvUXxmbULAspIvMk6t4yMTQ== X-Received: by 2002:a17:903:2349:b0:1d3:dc24:351 with SMTP id c9-20020a170903234900b001d3dc240351mr3531541plh.84.1705348049329; Mon, 15 Jan 2024 11:47:29 -0800 (PST) Received: from ?IPV6:2804:1b3:a7c2:2787:1d58:abc7:72ea:8c9c? ([2804:1b3:a7c2:2787:1d58:abc7:72ea:8c9c]) by smtp.gmail.com with ESMTPSA id t16-20020a170902e85000b001d3d8c04331sm7956129plg.64.2024.01.15.11.47.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Jan 2024 11:47:28 -0800 (PST) Message-ID: <41ebee39-2fe5-4ea0-ae6d-94321d2e59d0@linaro.org> Date: Mon, 15 Jan 2024 16:47:25 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: RFC: A way to get a TID from a pthread_t handler Content-Language: en-US To: Trevor Gross , Florian Weimer Cc: Trevor Gross via Libc-help , jistone@redhat.com, Carlos O'Donell References: <87a5pbv9na.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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: On 12/01/24 04:55, Trevor Gross wrote: > On Thu, Jan 11, 2024 at 4:32 PM Florian Weimer wrote: >> >> * Trevor Gross via Libc-help: >> >>> It seems like there isn't a good way to get the thread ID from a >>> pthread_t. If you are within the thread then you can call gettid(), >>> but there is no public API to get a spawned thread's TID after calling >>> pthread_create(). >>> >>> This value is stored in the pthread, so a new public function could >>> just be a basic getter: >>> >>> pid_t pthread_gettid(pthread_t threadid) >>> { >>> struct pthread *pd = (struct pthread *) threadid; >>> return pd->tid; >>> } >>> >>> Would an addition like this likely get accepted? Or is there anything >>> overlooked about an easier way to recover the spawned thread's TID? >> >> We should probably make a copy of the TID inside pthread_create and >> return that from pthread_gettid, instead of pd->tid that might be >> cleared by the kernel upon thread exit. This way, pthread_gettid >> remains valid until pthread_join is called. >> >> Thanks, >> Florian >> > > As in, store a second pid_t value within pthread? This sounds doable, > I think that would sidestep a lot of the problems listed in [1]. Maybe > it could also be used other places after a INVALID_TD_P check, such as > at [2], to still return something somewhat valid if the check returns > a false positive. > > Adding Adhemerval based on the thread, did you ever prototype an > implementation for this? (pthread_gettid_np, [1]) 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). So the question is which Linux support are you trying to expose by an external call that can not be factored by a possible pthread extension and if this interface does make sense. > > - Trevor > > [1]: https://inbox.sourceware.org/libc-alpha/6d79a213-0df2-be8e-3596-e010f366a34f@linaro.org/ > [2]: https://github.com/bminor/glibc/blob/520b1df08de68a3de328b65a25b86300a7ddf512/nptl/pthread_getcpuclockid.c#L38