This test would be incorrect if we treated VMs as having 0 physicals as suggested in your comment above.  I could see going either way. VM's technically have no physical cpus, but in environments which don't overcommit cpu resources, the apparent cpu count within the guest does mostly correspond to either SMT or full physical cores dedicated to this guest from the host.  It seems to me the intent of these methods is to allow library clients to calculate an appropriate amount of concurrency to ask for; in that case, it's probably more appropriate for `physical_processor_count` to fall back to `processor_count` so the client code doesn't need special case to handle when the former returns 0.