Merging upstream version 6.8.

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

1 files changed, 76 insertions, 0 deletions

diff --git a/man/man2/sched_yield.2 b/man/man2/sched_yield.2
new file mode 100644
index 0000000..e661927
--- /dev/null
+++ b/man/man2/sched_yield.2
@@ -0,0 +1,76 @@
+.\" Copyright (C) Tom Bjorkholm & Markus Kuhn, 1996
+.\"
+.\" SPDX-License-Identifier: GPL-2.0-or-later
+.\"
+.\" 1996-04-01 Tom Bjorkholm <tomb@mydata.se>
+.\"            First version written
+.\" 1996-04-10 Markus Kuhn <mskuhn@cip.informatik.uni-erlangen.de>
+.\"            revision
+.\"
+.TH sched_yield 2 2024-05-02 "Linux man-pages (unreleased)"
+.SH NAME
+sched_yield \- yield the processor
+.SH LIBRARY
+Standard C library
+.RI ( libc ", " \-lc )
+.SH SYNOPSIS
+.nf
+.B #include <sched.h>
+.P
+.B int sched_yield(void);
+.fi
+.SH DESCRIPTION
+.BR sched_yield ()
+causes the calling thread to relinquish the CPU.
+The thread is moved to the end of the queue for its static
+priority and a new thread gets to run.
+.SH RETURN VALUE
+On success,
+.BR sched_yield ()
+returns 0.
+On error, \-1 is returned, and
+.I errno
+is set to indicate the error.
+.SH ERRORS
+In the Linux implementation,
+.BR sched_yield ()
+always succeeds.
+.SH STANDARDS
+POSIX.1-2008.
+.SH HISTORY
+POSIX.1-2001 (but optional).
+POSIX.1-2008.
+.P
+Before POSIX.1-2008,
+systems on which
+.BR sched_yield ()
+is available defined
+.B _POSIX_PRIORITY_SCHEDULING
+in
+.IR <unistd.h> .
+.SH CAVEATS
+.BR sched_yield ()
+is intended for use with real-time scheduling policies (i.e.,
+.B SCHED_FIFO
+or
+.BR SCHED_RR ).
+Use of
+.BR sched_yield ()
+with nondeterministic scheduling policies such as
+.B SCHED_OTHER
+is unspecified and very likely means your application design is broken.
+.P
+If the calling thread is the only thread in the highest
+priority list at that time,
+it will continue to run after a call to
+.BR sched_yield ().
+.P
+Avoid calling
+.BR sched_yield ()
+unnecessarily or inappropriately
+(e.g., when resources needed by other
+schedulable threads are still held by the caller),
+since doing so will result in unnecessary context switches,
+which will degrade system performance.
+.SH SEE ALSO
+.BR sched (7)