sched_setaffinity failure

[ericeil]

On rs_preview build 14905:

sudo apt-get install dotnet-dev-1.0.0-preview2-003121

dotnet new

Replace Program.cs with the following:

using System;

namespace ConsoleApplication
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var p = System.Diagnostics.Process.GetCurrentProcess();
            Console.WriteLine(p.ProcessorAffinity);
            p.ProcessorAffinity = (IntPtr)1;
        }
    }
}

dotnet restore

dotnet run

On "real" Linux, this runs to completion. On Windows, I get a failure:

Unhandled Exception: System.ComponentModel.Win32Exception: Invalid argument
   at System.Diagnostics.Process.set_ProcessorAffinityCore(IntPtr value)
   at System.Diagnostics.Process.set_ProcessorAffinity(IntPtr value)
   at ConsoleApplication.Program.Main(String[] args)

ProcessorAffinityCore is calling sched_setaffinity, which apparently fails.

[sunilmut]

Thanks Eric. WSL currently does not fully support sched_setaffinity. I have opened a bug internally to track this.

[misenesi]

Thank you @ericeil for reporting the issue with repro steps.

I don’t see any sched_setaffinity calls, only sched_getaffinity calls (succeeding). What exactly is System.Diagnostics.Process.set_ProcessorAffinityCore(IntPtr value) trying to do?

[ericeil]

@misenesi:

The Linux implementation of set_ProcessorAffinityCore is here: https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.Process/src/System/Diagnostics/Process.Linux.cs#L103. It's effectively just a call to a native wrapper around sched_setaffinity; you can find the native wrapper code here: https://github.com/dotnet/corefx/blob/bffef76f6af208e2042a2f27bc081ee908bb390b/src/Native/Unix/System.Native/pal_process.cpp#L494.

[misenesi]

Thanks for the sources! I have fixed it to match Ubuntu behavior more closely now and the test is passing. However I came across something interesting. When sched_setaffinity actually gets called, the mask passed down isnt just set for the first processor, but for the 1st and 33rd. The mask passed down starts with:

0x00000001`00000001 (‭000100000000000000000000000000000001‬ in binary)

It is right at the edge of int32 and int64 and it looks like a possible bug to me on the C# side, since we are setting 1 here. Prior sched_getaffinity call returns 1...Am I missing something here?

Looking at the code, I am slightly suspicious of this piece of code, whether it does what we think it does:

if ((bits & static_cast<intptr_t>(1u << cpu)) != 0)

It might be interesting to see the assembly generated for the bitshift here. If operator << behaves more like a rotation (and 1u is 32bit...), then that 1 on 33rd position would make sense.