@ivanpovazan have made me aware today of the fact that we build and link cgroup.cpp variants and cgroupcpu.cpp macOS. Even though it doesn't cause any harm execution-wise, it is unused on it (we just effectively call statfs on "/sys/fs/cgroup" to check for the filesystem magic and return false since no cgroup filesystem is mounted there), there is no sense in having the code in.
We should still compile / link the code, but ifdef out everything that is trying to access cgroups. Only keep functions GetPhysicalMemoryUsed / GetRestrictedPhysicalMemoryLimit / PAL_GetCpuLimit / GetCpuLimit that it makes sense to preserve as they either have an implementation that contains non-cgroup fallback or might get one in the future.
@ivanpovazan have made me aware today of the fact that we build and link cgroup.cpp variants and cgroupcpu.cpp macOS. Even though it doesn't cause any harm execution-wise, it is unused on it (we just effectively call statfs on "/sys/fs/cgroup" to check for the filesystem magic and return false since no cgroup filesystem is mounted there), there is no sense in having the code in.
We should still compile / link the code, but ifdef out everything that is trying to access cgroups. Only keep functions
GetPhysicalMemoryUsed/GetRestrictedPhysicalMemoryLimit/PAL_GetCpuLimit/GetCpuLimitthat it makes sense to preserve as they either have an implementation that contains non-cgroup fallback or might get one in the future.