|
|
Subscribe / Log in / New account

Completing the pidfd API

Completing the pidfd API

Posted Sep 6, 2023 16:59 UTC (Wed) by bartoc (guest, #124262)
Parent article: Completing the pidfd API

Does this get rid of some shared data-structure in the kernel that maps PIDs to the actual resources of the process? I ask because I noticed that with pthreads one can write "pthread_detach(pthread_self())" to detach yourself, whereas presumably detaching yourself via a pidfd you got from "yourself" would be a no-op as any resources would be held open by the other pidfd opened by your parent thread. I noticed this when implementing pthreads/c11 threads on windows, where threads are represented by HANDLES that are recounted and work similarly to files. On windows I came to the conclusion that allowing threads to detach themselves would require a shared data-structure holding the mapping of PIDs to HANDLES.


to post comments

Completing the pidfd API

Posted Oct 17, 2024 0:34 UTC (Thu) by jengelh (guest, #33263) [Link]

>one can write "pthread_detach(pthread_self())" to detach yourself, whereas presumably detaching yourself via a pidfd you got from "yourself" would be a no-op

In glibc-nptl, pthread_self and _detach are functions that involve just userspace. There is not going to be a deadlock/deadlock-avoiding-noop as you envisioned.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds