[PATCH] Cygwin: Fix return value of sched_getaffinity
Tue Jun 25 08:17:00 GMT 2019
Corinna Vinschen wrote:
> Hi Mark,
> On Jun 24 22:25, Mark Geisert wrote:
>> Return what the documentation says, instead of a misreading of it.
>> winsup/cygwin/sched.cc | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> diff --git a/winsup/cygwin/sched.cc b/winsup/cygwin/sched.cc
>> index e7b44d319..8f24bf80d 100644
>> --- a/winsup/cygwin/sched.cc
>> +++ b/winsup/cygwin/sched.cc
>> @@ -608,7 +608,7 @@ done:
>> /* Emulate documented Linux kernel behavior on successful return */
>> - status = wincap.cpu_count ();
>> + status = sizeof (cpu_set_t);
> Wait... what docs are you referring to? The Linux man page in Fedora 29
> On success, sched_setaffinity() and sched_getaffinity() return 0. On
> error, -1 is returned, and errno is set appropriately.
I've been using http://man7.org/linux/man-pages/man2/sched_setaffinity.2.html
which has the text you quoted under the RETURN VALUE heading, but has the
following further down the page under the heading "C library/kernel differences":
| This manual page describes the glibc interface for the CPU affinity
| calls. The actual system call interface is slightly different, with
| the mask being typed as unsigned long *, reflecting the fact that the
| underlying implementation of CPU sets is a simple bit mask.
| On success, the raw sched_getaffinity() system call returns the
| number of bytes placed copied into the mask buffer; this will be the
| minimum of cpusetsize and the size (in bytes) of the cpumask_t data
| type that is used internally by the kernel to represent the CPU set
| bit mask.
I see now that that 2nd paragraph has actually been updated since I printed it
out in April so I'll need to update the patch yet again.
The taskset(1) utility in util-linux actually depends on the kernel return value
that glibc doesn't return. On Cygwin there is only one "syscall" interface so I
have to have sched_getaffinity() return a nonzero value on success like the
Linux kernel does.
> Also, while at it, would you mind to rearrange the code a bit at this
> point? I think it's a bit puzzeling that status indicates an error code
> as well as the non-errno return code from this function. Kind of like
> if (status)
> set_errno (status)
> return -1;
> return 0;
Sure, no problem. If you're OK with my rationale above I'll submit a revised
patch with this adjustment included.
More information about the Cygwin-patches