Sounds about right, 0 is just pretty useless/unexpected return value and if
you do things like 0 times do etc things fall apart :D
 so physical == 0 ? physical : virtual sounds like a good solution, can you
update your pull to use this / does this still solve your problem ?


On Sat, Aug 17, 2013 at 3:58 PM, Devin Ben-Hur <notifications@github.com>wrote:

> In spec/parallel_spec.rb:
>
> >        pending if ENV["TRAVIS"]
> > -      [Parallel.processor_count, Parallel.processor_count / 2].should include Parallel.physical_processor_count
> > +      (Parallel.processor_count % Parallel.physical_processor_count).should == 0
>
> 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.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/grosser/parallel/pull/67/files#r5830060>
> .
>