This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Remove cached PID/TID in clone
On 11/08/2016 08:58 PM, Adhemerval Zanella wrote:
The tid fields is basically used internally on pthread implementations
(including getpid) and since correct usage means thread *must* be
created using pthread_create we are sure the tid field will be
correctly set due 'set_tid_address' from __pthread_initialize_pids.
Thanks for the explanation.
I really think we should document the clone system call wrapper and
spell out these requirements, but that's a separate matter.
> Please rename to “pid_unused” or something like that, to make sure it's no longer referenced.
I renamed it on my local branch and I also updated the change spot
that it incur:
diff --git a/nptl_db/structs.def b/nptl_db/structs.def
index a9b621b..1cb6a46 100644
@@ -48,7 +48,6 @@ DB_STRUCT (pthread)
DB_STRUCT_FIELD (pthread, list)
DB_STRUCT_FIELD (pthread, report_events)
DB_STRUCT_FIELD (pthread, tid)
-DB_STRUCT_FIELD (pthread, pid)
DB_STRUCT_FIELD (pthread, start_routine)
DB_STRUCT_FIELD (pthread, cancelhandling)
DB_STRUCT_FIELD (pthread, schedpolicy)
Have you tested that thread debugging still works after these changes
(at least on one architecture)?
The patch also removes the TID caching in clone. My understanding for
such semantic is try provide some pthread usage after a user program
issue clone directly (as done by thread creation with CLONE_PARENT_SETTID
and pthread tid member). However, as stated before in multiple threads,
“discussion threads”? ☹
GLIBC provides clone syscalls without further supporting all this
semantics. It means that, although GLIBC currently tries a better effort,
since it does not make any more guarantees, specially for newer and newer
I don't quite understand the above part.
* sysdeps/unix/sysv/linux/getpid.c: Likewise.
This needs updating (file was removed).
I do not have further comments, but I have not reviewed the assembler
language implementations (only i386/x86_64). I support the removal of
PID caching, though.