[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] core-count: A new program to count the number of cpu cores

From: Pádraig Brady
Subject: Re: [PATCH] core-count: A new program to count the number of cpu cores
Date: Wed, 04 Nov 2009 16:38:38 +0000
User-agent: Thunderbird (X11/20071008)

Paolo Bonzini wrote:
> On 11/04/2009 01:24 AM, Pádraig Brady wrote:
>> BTW, it wouldn't be ambiguous to the program, nor would it
>> be different than the existing meaning, but as you say,
>> users could mistakenly do -P0 when they meant -0P.
>> So I'll make the arg mandatory, but what to choose?
>> "n" is all I can come up with in my half awake state.
>> I'll sleep on it.
> I propose that --parallel is the same as -P<num-procs>.
> I would go a step further and deprecate --num-procs=NNN while making
> --parallel[=NNN] the new "long" version of -P.  Long options (unlike
> short options) are safer when it comes to optional arguments, so
> --parallel's argument could indeed be optional (while -P would keep the
> mandatory argument).  The name change would be needed however to have an
> optional argument.

Right, that would mean that `xargs --parallel 4` would give an explicit error,
while if we change the existing options to have an optional param then
existing scripts with `xargs -P 4` or `xargs --max-procs 4` would now fail.

So there's the new --parallel option above or the alternative
of adding say an "auto" param to the existing --max-procs|-P option.

1. --parallel

  nicer name IMHO
  simpler syntax when you want to use all available processors
  an optional param could be very slightly confusing
  not having an optional param on the -P option is confusing
  it's a new option for people to notice/disregard

2. --max-procs=auto|-Pauto

  symmetric less confusing params
  an extension of an existing option
  syntax is not as nice IMHO

3. --max-procs=$(nproc)

A third option is to leave this out of xargs altogether
so that one would need to do xargs -P$(nproc).
$(nproc) should be at least as available as a new xargs I think.
If we do this then I'll still send a patch that mentions
$(nproc) in the xargs docs.

I'm leaning towards 3. now given the slight awkwardness of 1. and 2.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]