Adding upstream version 6.7.upstream/6.7

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 28 insertions, 28 deletions

diff --git a/man7/pthreads.7 b/man7/pthreads.7
index 2c00798..6d4a5e3 100644
--- a/man7/pthreads.7
+++ b/man7/pthreads.7
@@ -2,7 +2,7 @@
 .\"
 .\" SPDX-License-Identifier: Linux-man-pages-copyleft
 .\"
-.TH pthreads 7 2023-03-18 "Linux man-pages 6.05.01"
+.TH pthreads 7 2023-10-31 "Linux man-pages 6.7"
 .SH NAME
 pthreads \- POSIX threads
 .SH DESCRIPTION
@@ -12,7 +12,7 @@ A single process can contain multiple threads,
 all of which are executing the same program.
 These threads share the same global memory (data and heap segments),
 but each thread has its own stack (automatic variables).
-.PP
+.P
 POSIX.1 also requires that threads share a range of other attributes
 (i.e., these attributes are process-wide rather than per-thread):
 .IP \[bu] 3
@@ -57,7 +57,7 @@ measurements of the consumption of CPU time
 .RB ( times (2))
 and resources
 .RB ( getrusage (2))
-.PP
+.P
 As well as the stack, POSIX.1 specifies that various other
 attributes are distinct for each thread, including:
 .IP \[bu] 3
@@ -77,7 +77,7 @@ alternate signal stack
 .IP \[bu]
 real-time scheduling policy and priority
 .RB ( sched (7))
-.PP
+.P
 The following Linux-specific features are also per-thread:
 .IP \[bu] 3
 capabilities (see
@@ -104,12 +104,12 @@ This identifier is returned to the caller of
 .BR pthread_create (3),
 and a thread can obtain its own thread identifier using
 .BR pthread_self (3).
-.PP
+.P
 Thread IDs are guaranteed to be unique only within a process.
 (In all pthreads functions that accept a thread ID as an argument,
 that ID by definition refers to a thread in
 the same process as the caller.)
-.PP
+.P
 The system may reuse a thread ID after a terminated thread has been joined,
 or a detached thread has terminated.
 POSIX says: "If an application attempts to use a thread ID whose
@@ -118,11 +118,11 @@ lifetime has ended, the behavior is undefined."
 A thread-safe function is one that can be safely
 (i.e., it will deliver the same results regardless of whether it is)
 called from multiple threads at the same time.
-.PP
+.P
 POSIX.1-2001 and POSIX.1-2008 require that all functions specified
 in the standard shall be thread-safe,
 except for the following functions:
-.PP
+.P
 .in +4n
 .EX
 asctime()
@@ -224,10 +224,10 @@ wctomb()
 An async-cancel-safe function is one that can be safely called
 in an application where asynchronous cancelability is enabled (see
 .BR pthread_setcancelstate (3)).
-.PP
+.P
 Only the following functions are required to be async-cancel-safe by
 POSIX.1-2001 and POSIX.1-2008:
-.PP
+.P
 .in +4n
 .EX
 pthread_cancel()
@@ -242,10 +242,10 @@ If a thread is cancelable, its cancelability type is deferred,
 and a cancelation request is pending for the thread,
 then the thread is canceled when it calls a function
 that is a cancelation point.
-.PP
+.P
 The following functions are required to be cancelation points by
 POSIX.1-2001 and/or POSIX.1-2008:
-.PP
+.P
 .\" FIXME
 .\" Document the list of all functions that are cancelation points in glibc
 .in +4n
@@ -310,10 +310,10 @@ write()
 writev()
 .EE
 .in
-.PP
+.P
 The following functions may be cancelation points according to
 POSIX.1-2001 and/or POSIX.1-2008:
-.PP
+.P
 .in +4n
 .EX
 access()
@@ -545,13 +545,13 @@ wprintf()
 wscanf()
 .EE
 .in
-.PP
+.P
 An implementation may also mark other functions
 not specified in the standard as cancelation points.
 In particular, an implementation is likely to mark
 any nonstandard function that may block as a cancelation point.
 (This includes most functions that can touch files.)
-.PP
+.P
 It should be noted that even if an application is not using
 asynchronous cancelation, that calling a function from the above list
 from an asynchronous signal handler may cause the equivalent of
@@ -669,7 +669,7 @@ the requirements of the POSIX.1 specification and better performance
 when creating large numbers of threads.
 NPTL is available since glibc 2.3.2,
 and requires features that are present in the Linux 2.6 kernel.
-.PP
+.P
 Both of these are so-called 1:1 implementations, meaning that each
 thread maps to a kernel scheduling entity.
 Both threading implementations employ the Linux
@@ -707,7 +707,7 @@ more information than usual, but which do not share a common process ID.)
 LinuxThreads threads (including the manager thread)
 are visible as separate processes using
 .BR ps (1).
-.PP
+.P
 The LinuxThreads implementation deviates from the POSIX.1
 specification in a number of ways, including the following:
 .IP \[bu] 3
@@ -789,13 +789,13 @@ With NPTL, all of the threads in a process are placed
 in the same thread group;
 all members of a thread group share the same PID.
 NPTL does not employ a manager thread.
-.PP
+.P
 NPTL makes internal use of the first two real-time signals;
 these signals cannot be used in applications.
 See
 .BR nptl (7)
 for further details.
-.PP
+.P
 NPTL still has at least one nonconformance with POSIX.1:
 .IP \[bu] 3
 Threads do not share a common nice value.
@@ -804,7 +804,7 @@ Threads do not share a common nice value.
 .\" Sep 08: there is a patch by Denys Vlasenko to address this
 .\" "make setpriority POSIX compliant; introduce PRIO_THREAD extension"
 .\" Monitor this to see if it makes it into mainline.
-.PP
+.P
 Some NPTL nonconformances occur only with older kernels:
 .IP \[bu] 3
 The information returned by
@@ -831,7 +831,7 @@ However, a new thread's alternate signal stack settings
 are copied from the thread that created it, so that
 the threads initially share an alternate signal stack
 (fixed in Linux 2.6.16).
-.PP
+.P
 Note the following further points about the NPTL implementation:
 .IP \[bu] 3
 If the stack size soft resource limit (see the description of
@@ -852,17 +852,17 @@ Since glibc 2.3.2, the
 .BR getconf (1)
 command can be used to determine
 the system's threading implementation, for example:
-.PP
+.P
 .in +4n
 .EX
 bash$ getconf GNU_LIBPTHREAD_VERSION
 NPTL 2.3.4
 .EE
 .in
-.PP
+.P
 With older glibc versions, a command such as the following should
 be sufficient to determine the default threading implementation:
-.PP
+.P
 .in +4n
 .EX
 bash$ $( ldd /bin/ls | grep libc.so | awk \[aq]{print $3}\[aq] ) | \e
@@ -885,7 +885,7 @@ of LinuxThreads.
 (broken) application that depends on some nonconformant behavior
 in LinuxThreads.)
 For example:
-.PP
+.P
 .in +4n
 .EX
 bash$ $( LD_ASSUME_KERNEL=2.2.5 ldd /bin/ls | grep libc.so | \e
@@ -904,9 +904,9 @@ bash$ $( LD_ASSUME_KERNEL=2.2.5 ldd /bin/ls | grep libc.so | \e
 .BR attributes (7),
 .BR futex (7),
 .BR nptl (7),
-.BR sigevent (7),
+.BR sigevent (3type),
 .BR signal (7)
-.PP
+.P
 Various Pthreads manual pages, for example:
 .BR pthread_atfork (3),
 .BR pthread_attr_init (3),