Date: Fri, 21 Jun 2002 16:51:51 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Mikhail Teterin <mi+mx@aldan.algebra.com> Cc: Dag-Erling Smorgrav <des@ofug.org>, Juli Mallett <jmallett@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: feature request for xargs Message-ID: <3D13BC17.77E46CC9@mindspring.com> References: <200206200706.g5K76M514469@freefall.freebsd.org> <200206211110.45597.mi%2Bmx@aldan.algebra.com> <3D13A6BB.E4FB6085@mindspring.com> <200206211850.59359.mi%2Bmx@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mikhail Teterin wrote: > = Give up. 8-). > > Ok, ok. One last attempt... > > = It's a bad example. There are good examples. But the delete example, > = trading an "rm" for a fork+exec and an async rm doesn't win. The > = problem is that the parent directory is going to be locked against > = other processes during the rm anyway. > > My calculations are, the number of files in one directory (on average) > will be far below the maximum number of arguments. So all files in a > usual directory will be processed sequentionally by one of the many rm-s. THis would work if you were dividing up the globbing space with xargs. THat's not what it does, though. What it does is take a bunch of input that trickles in, and when there is enough of it (or an EOF, if there isn't enough), it forks and exec's a command, waiting for the command to complete so it can reap the status code. Any optimization you get has to result from not waiting and reaping, and the command not having completed by the time enough arguments trickle in that you fork and exec the next command. So your basic assumptions have to be that: o The command xargs will run takes a relatively long time o There is no contention between multiple instances of the command (like parent directory vnode locks, for the lookup for "rm") It's not like "xargs -j4" gets you a four way pipe splitter. You would probably get a similar effect by just allowing any number of commands to be backgrounded as a result of xargs, and then limiting the command line length more than the system does (e.g. limit it to 256 bytes instead, to reduce the latency waiting for mor arguments to trickle in). Like I said, merely harmless and redundant, for most usages, unless the command has a relatively long duration. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D13BC17.77E46CC9>