bug-gnulib
[Top][All Lists]
Advanced

[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 2.0.0.6 (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

advantages
  nicer name IMHO
  simpler syntax when you want to use all available processors
disadvantages
  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

advantages
  symmetric less confusing params
  an extension of an existing option
disadvantages
  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.

cheers,
Pádraig.




reply via email to

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