bugfindutils - Bugs: bug #30504, bug/rfe....the "-P"...

 
 

bug #30504: bug/rfe....the "-P" option seems to be unusable by itself

Submitted by:  Linda A. Walsh <law>
Submitted on:  Wed 21 Jul 2010 05:24:20 AM UTC  
 
Category: xargsSeverity: 1 - Wish
Item Group: NoneStatus: Works For Me
Privacy: PublicAssigned to: James Youngman <jay>
Originator Name: Open/Closed: Closed
Release: 4.4.0Fixed Release: None

Discussion locked!

 

(Jump to the original submission Jump to the original submission)

Sun 15 May 2011 09:45:52 AM UTC, comment #7:

As I mentioned before, I'd like to move discussion of this possible change to the mailing list, so that I can get a better idea of the consensus opinion. So, I'll close this bug here.

James Youngman <jay>
Project AdministratorIn charge of this item.
Thu 07 Oct 2010 09:58:27 AM UTC, comment #6:

The mailing list address is given in the BUGS section of the manpage:

The best way to report a bug is to use the form at http://savannah.gnu.org/bugs/?group=findutils. The reason for this is that you will then be able to track progress in fixing the problem. Other comments about xargs(1) and about the findutils package in general can be sent to the bug-findutils mailing list. To join the list, send email to bug-findutils-request@gnu.org.

James Youngman <jay>
Project AdministratorIn charge of this item.
Tue 17 Aug 2010 11:39:24 AM UTC, comment #5:

That's the nature of the bug/comment.

The -P option by it self is not usable.

You don't need to do any work if you don't want to do it. I already have working code as the modification is trivial.

I'm simple suggesting that the -P when used in absence of any other argument length directives means to use processes to process the arguments. I don't see the complexity in that argument.

As I mentioned before. What other interpretation would you
place on the use of a single -P switch with no others?

i.e.:
xargs -0 -P xxyz

You keep speaking about list. what list are you talking about?
I looked for a list before posting the bug here and don't recall finding one. bugs-xargs, bugs-findutils, didnt' seem to exist as I recall, but I may have tried some wrong address.

Linda A. Walsh <law>
Mon 16 Aug 2010 11:39:48 PM UTC, comment #4:

That's why the documentation, at the moment, says this:

--max-procs=max-procs
-P max-procs

Run up to max-procs processes at a time; the default is 1. If
max-procs is 0, xargs will run as many processes as possible at
a time. Use the -n option with -P; otherwise chances are that
only one exec will be done.

If there is a consensus on the list for an alternative approach (for example launching a child as soon as (fewer than max-procs children are executing) and (at least one argument has not been consumed) then I'll consider working on it.

James Youngman <jay>
Project AdministratorIn charge of this item.
Sun 15 Aug 2010 01:23:57 PM UTC, comment #3:

'if the input is sufficiently large'?

In my case it would have to exceed 2MB of characters.

In a practical sense that means it would never use more than one.

Thus my assertion that the algorithm is flawed.

If a user uses -P by itself, what, exactly, do you think they mean by typing that in? That they only want parallel processing if input exceeds 2MB, or that they want parallel processing?

Um...The former doesn't make rational sense.

Linda A. Walsh <law>
Sun 15 Aug 2010 12:18:34 PM UTC, comment #2:

Clearly -P would result in parallel processing if the input is sufficiently large.

It's not going to be possible for xargs to choose an optimal strategy; at any point it would need to be able to choose between reading another argument (which may cause us to sleep, avoidably so if the input is a pipe) and execing a child.

My preference has been to rely on the user to know both
1. the computational workload of each argument, on average
and
2. the amount of resources they want this job to use up ("use the whole machine" is not always the preferred behaviour)

I'd like to see more debate on the list - in other words some kind of consensus for how much of a problem people find this in general and what the reasonable solutions are - before encouraging you to write a patch which may not be accepted.

James Youngman <jay>
Project AdministratorIn charge of this item.
Mon 02 Aug 2010 09:45:20 AM UTC, comment #1:

Is a patch needed to move this fix forward?

Linda A. Walsh <law>
Wed 21 Jul 2010 05:24:20 AM UTC, original submission:

I'd like to suggest the -P option be 'fixed' to be usable by itself.
If I use the -P option by itself I want xargs _ to try_ to use up to
"N" processors... Right now, it doesn't try at all unless you force
it to by using the -n/-l options.

That makes it sorta worthless...

I'd like to decide what is a good number of processes to run concurrently for
a given "program" (that is to be run under xargs) and have xargs work out the
rest.

I don't know what the total number of args is, so the only valid option, most
of the time, is -n1.
I'd like to suggest that the program default to -n1 when -P is specified alone --
making a -P option, by itself, "useful"...otherwise, my 'max' cpus values is
ignored and xargs will never use more than 1 cpu. That's certainly NOT
the intent if someone specifies "-P" by itself without "-n"...

Wouldn't this make sense?

yes?

thanks!

Linda

Linda A. Walsh <law>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jay (Posted a comment)
  • -unavailable- added by law (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 15 May 2011 09:45:52 AM UTCjaySeverity3 - Normal=>1 - Wish
      StatusNone=>Works For Me
      Assigned toNone=>jay
      Open/ClosedOpen=>Closed
      Discussion LockUnlocked=>Locked

    Back to the top


    Powered by Savane 3.1-cleanup1