This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PING: fix ARG_MAX


On Mon, Sep 12, 2005 at 10:09:55PM -0600, Eric Blake wrote:
>Also, the argument brought up on the findutils mailing list was that
>beyond a certain size, the cost of processing each argument starts to
>outweigh the benefits of forking fewer tasks, to the point that the
>difference between a 32k ARG_MAX vs.  a 1M ARG_MAX falls in the noise
>when the same amount of data is divided by xargs to as few runs as
>possible, so a 32k limit is not really penalizing cygwin apps.

If this is really true, then the findutils configury should be
attempting some kind of timing which finds that magic point where it
should be ignoring _SC_ARG_MAX.  It shouldn't be vaguely assuming that
it is in its best interests to ignore it because someone thinks that the
cost of processing each argument outweighs the benefits of forking fewer
tests.

Given that cost of forking is much more expensive on cygwin than on
other systems I really don't see how you can use this argument anyway
and, IMO, it doesn't make much sense on standard UNIX either.  If you
create more processes via fork you are invoking the OS and incurring
context switches.  You're still processing the same number of arguments
but you're just going to the OS to handle them more often.  I don't see
how that's ever a win.

I'm willing to be proven wrong by hard data but I think that you and the
findutils mailing list shouldn't be making assumptions without data to
back them up.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]