.\" the source, must acknowledge the copyright and authors of this work.
.\" %%%LICENSE_END
.\"
-.TH GETPID 2 2015-07-23 "Linux" "Linux Programmer's Manual"
+.TH GETPID 2 2019-03-06 "Linux" "Linux Programmer's Manual"
.SH NAME
getpid, getppid \- get process identification
.SH SYNOPSIS
.B #include <sys/types.h>
.br
.B #include <unistd.h>
-.sp
+.PP
.B pid_t getpid(void);
.br
.B pid_t getppid(void);
.SH DESCRIPTION
.BR getpid ()
-returns the process ID of the calling process.
+returns the process ID (PID) of the calling process.
(This is often used by
routines that generate unique temporary filenames.)
-
+.PP
.BR getppid ()
returns the process ID of the parent of the calling process.
+This will be either the ID of the process that created this process using
+.BR fork (),
+or, if that process has already terminated,
+the ID of the process to which this process has been reparented (either
+.BR init (1)
+or a "subreaper" process defined via the
+.BR prctl (2)
+.BR PR_SET_CHILD_SUBREAPER
+operation).
.SH ERRORS
These functions are always successful.
.SH CONFORMING TO
-POSIX.1-2001, 4.3BSD, SVr4.
+POSIX.1-2001, POSIX.1-2008, 4.3BSD, SVr4.
.SH NOTES
If the caller's parent is in a different PID namespace (see
.BR pid_namespaces (7)),
.BR getppid ()
returns 0.
+.PP
+From a kernel perspective,
+the PID (which is shared by all of the threads in a multithreaded process)
+is sometimes also known as the thread group ID (TGID).
+This contrasts with the kernel thread ID (TID),
+which is unique for each thread.
+For further details, see
+.BR gettid (2)
+and the discussion of the
+.BR CLONE_THREAD
+flag in
+.BR clone (2).
.\"
.SS C library/kernel differences
-Since glibc version 2.3.4,
+From glibc version 2.3.4 up to and including version 2.24,
the glibc wrapper function for
.BR getpid ()
-caches PIDs,
-so as to avoid additional system calls when a process calls
+cached PIDs,
+with the goal of avoiding additional system calls when a process calls
.BR getpid ()
repeatedly.
-Normally this caching is invisible,
-but its correct operation relies on support in the wrapper functions for
+Normally this caching was invisible,
+but its correct operation relied on support in the wrapper functions for
.BR fork (2),
.BR vfork (2),
and
.BR clone (2):
-if an application bypasses the glibc wrappers for these system calls by using
+if an application bypassed the glibc wrappers for these system calls by using
.BR syscall (2),
then a call to
.BR getpid ()
-in the child will return the wrong value
-(to be precise: it will return the PID of the parent process).
+in the child would return the wrong value
+(to be precise: it would return the PID of the parent process).
.\" The following program demonstrates this "feature":
.\"
.\" #define _GNU_SOURCE
.\" }
.\" wait(NULL);
.\"}
-See also
-.BR clone (2)
-for discussion of a case where
+In addition, there were cases where
.BR getpid ()
-may return the wrong value even when invoking
+could return the wrong value even when invoking
.BR clone (2)
via the glibc wrapper function.
+(For a discussion of one such case, see BUGS in
+.BR clone (2).)
+Furthermore, the complexity of the caching code had been
+the source of a few bugs within glibc over the years.
+.PP
+Because of the aforementioned problems,
+since glibc version 2.25, the PID cache is removed:
+.\" commit c579f48edba88380635ab98cb612030e3ed8691e
+.\" https://sourceware.org/glibc/wiki/Release/2.25#pid_cache_removal
+calls to
+.BR getpid ()
+always invoke the actual system call, rather than returning a cached value.
+.\" FIXME .
+.\" Review progress of https://bugzilla.redhat.com/show_bug.cgi?id=1469757
+.PP
+On Alpha, instead of a pair of
+.BR getpid ()
+and
+.BR getppid ()
+system calls, a single
+.BR getxpid ()
+system call is provided, which returns a pair of PID and parent PID.
+The glibc
+.BR getpid ()
+and
+.BR getppid ()
+wrapper functions transparently deal with this.
+See
+.BR syscall (2)
+for details regarding register mapping.
.SH SEE ALSO
.BR clone (2),
.BR fork (2),
+.BR gettid (2),
.BR kill (2),
.BR exec (3),
.BR mkstemp (3),