Regarding API design, I think the most relevant information is how many cores are effectively available to the current process. That should be the most straightforward method.
Ideally, I'd like cpu_count to return the effective count with a fallback to total count on systems where there's no difference. And then we could have separate methods total_cpu_count and effective_cpu_count on top of that. Not sure if the latter is relevant, though.
That would change the semantics of cpu_count a little bit, but it might be just fine.

I personally prefer different files very much. It might be debatable when there's more shared code, but here it's completely distinct code for different OSes.

And we should add a spec for the new API method(s). At least make sure that it generally works.

Win32:

# winbase.h
lib LibC
  alias DWORD_PTR = ULONG_PTR

  fun GetProcessAffinityMask(hProcess : HANDLE, lpProcessAffinityMask : DWORD_PTR*, lpSystemAffinityMask : DWORD_PTR*) : BOOL
end

if LibC.GetProcessAffinityMask(LibC.GetCurrentProcess, out process_affinity, out _) == 0
  raise RuntimeError.from_winerror("GetProcessAffinityMask")
end
process_affinity.popcount

This works as long as the process does not opt in to using multiple processor groups, which is relevant when there are more than 64 logical processors present: https://learn.microsoft.com/en-us/windows/win32/procthread/processor-groups

@HertzDevil thank you 🙇

@straight-shoota But the split files don't tell which target use what (which sysconf? which sysctl?) and it becomes awkward to know where to put the linux implementation for the effective cpu count.

Yes, the current file names are not great.
We should be fine with three files cpu_count_unix.cr, cpu_count_linux.cr, cpu_count_bsd.cr.

Now with the implementation for all the targets that support it.