[patch v1] manual: add sched_getcpu()

[Collin Funk]

Hi DJ,

DJ Delorie <dj@redhat.com> writes:

> diff --git a/manual/resource.texi b/manual/resource.texi
> index a9b4b68e2f..39df1c4cb6 100644
> --- a/manual/resource.texi
> +++ b/manual/resource.texi
> @@ -1653,6 +1653,22 @@ The operating system does not support this function.
>  This function is Linux-specific and is declared in @file{sched.h}.
>  @end deftypefun
>  
> +@deftypefun int sched_getcpu (void)
> +@standards{Linux, <sched.h>}
> +
> +Similar to @code{getcpu} but with a simpler interface.  On success,
> +returns a nonnegative number identifying the CPU on which the current
> +thread is running.  Returns @code{-1} on failure.  The following
> +@code{errno} error condition is defined for this function:
> +
> +@table @code
> +@item ENOSYS
> +The operating system does not support this function.
> +@end table
> +
> +This function is Linux-specific and is declared in @file{sched.h}.
> +@end deftypefun
> +
>  Here's an example of how to use most of the above to limit the number
>  of CPUs a process runs on, not including error handling or good logic
>  on CPU choices:

Shouldn't it have @saftey annotations? I assume that it would be the
same as sched_getcpu, '@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}'.

The rest of the patch is good though.

Also, I find the note in the man-pages useful [1]:

       The call

           cpu = sched_getcpu();

       is equivalent to the following getcpu(2) call:

           int c, s;
           s = getcpu(&c, NULL);
           cpu = (s == -1) ? s : c;

Not sure if it is worth adding something similar to the glibc manual. It
can always be added later though.

Collin

[1] https://www.man7.org/linux/man-pages/man3/sched_getcpu.3.html#NOTES