From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 19DE03857C77; Thu, 27 May 2021 19:32:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 19DE03857C77 From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug nptl/27880] Please provide a pthread pid accessor Date: Thu, 27 May 2021 19:32:19 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: adhemerval.zanella at linaro dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: adhemerval.zanella at linaro dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2021 19:32:20 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27880 --- Comment #10 from Adhemerval Zanella --- It seems that this is trickier than it seems, some issues we might considere first: 1. What should we do with detached threads? As for pthread_kill, issuing a pthread_gettid_np might use an invalid handler (since the pthread_t identif= ier might be reused). This only solution I have is to define it as undefined behavior, this is not great but to proper support it would incur to keep tracking or all possible pthread_t identifiers (we already keep the glibc provided stacks, dl_stack_cache, so it would be a matter to include the user provided one in the list as special entries). 2. I think that once we provide this API, developers will start to use o query if a thread is alive and I am not sure if this is really the proper A= PI for this. This is the same issue as 1. 3. How do we handle the concurrent access between pthread_join and pthread_gettid_np? Once a pthread_join is issued, the pthread_t identifier might be reused and accessing it should be invalid. pthread_join first synchronizes using 'joinid' to avoid concurrent pthread_join and then wait = the kernel signal on 'tid' that the thread has finished. The 'pthread_gettid_n= p' naive check would just do a atomic load on tid, however it might read a transient value between pthread_join 'joinid' setup and the futex wait. I = am not sure how to handle it correctly. Also, MacOSX signature is: int pthread_gettid_np (pthread_t thread, uint64_t *thread_id) And it returns the current thread identification if THREAD is NULL, returns ESRCH for invalid handle (the 1. and 2. issue below), and also consults the kernel if the identifier can no be obtained. I think for possible glibc symbols we should use a pid_t instead, the NULL special arguments is also tricky because if by POSIX pthread_t might be NULL (this is an implementation detail), for ESRCH we can our INVALID_NOT_TERMINATED_TD_P (which not the best solution, but it the current pratice). --=20 You are receiving this mail because: You are on the CC list for the bug.=