genpkgmetadata.py

[James Antill]

genpkgmetadata.py | 3 +++
1 file changed, 3 insertions(+)

New commits:
commit 6a3315bfe7704d277c43a8ec5dd3733350105e9e
Author: James Antill <***@and.org>
Date: Thu Feb 16 11:29:26 2012 -0500

Limit number of workers to 128 (should be enough for anyone :).

diff --git a/genpkgmetadata.py b/genpkgmetadata.py
index ce8e452..9bf8c8d 100755
--- a/genpkgmetadata.py
+++ b/genpkgmetadata.py
@@ -145,6 +145,9 @@ def parse_args(args, conf):
else:
directories = argsleft

+ if opts.workers >= 128:
+ errorprint(_('Warning: More than 128 workers is a lot. Limiting.'))
+ opts.workers = 128
if opts.sumtype == 'sha1':
errorprint(_('Warning: It is more compatible to use sha instead of sha1'))

[Ville Skyttä]

Post by James Antill
Limit number of workers to 128 (should be enough for anyone :).

Sure, but out of curiosity, why?

[seth vidal]

On Sat, 18 Feb 2012 10:29:46 +0200

Post by Ville Skyttä

Post by James Antill
Limit number of workers to 128 (should be enough for anyone :).

Sure, but out of curiosity, why?

Number of workers is bound pretty tightly to number of processors/cores
you have.

-sv

[Ville Skyttä]

Post by seth vidal
On Sat, 18 Feb 2012 10:29:46 +0200

Post by Ville Skyttä

Post by James Antill
Limit number of workers to 128 (should be enough for anyone :).

Sure, but out of curiosity, why?

Number of workers is bound pretty tightly to number of processors/cores
you have.

That still doesn't answer the question why this particular hunk of code
was added, but ... meh, nevermind.

[James Antill]

Post by Ville Skyttä

Post by James Antill
Limit number of workers to 128 (should be enough for anyone :).

Sure, but out of curiosity, why?

Well if the user does --workers=666666 ... I think we can both agree
bad things will probably happen. You think the limit should be higher? I
picked 128 kind of randomly, although --workers=0 will still do it as
number of cores even if you have 1024 cores.

[Ville Skyttä]

Post by James Antill
Well if the user does --workers=666666 ... I think we can both agree
bad things will probably happen. You think the limit should be higher?

No, I think "don't do that, then" is perfectly adequate advice for cases
like that; no code needed for that nor for every other "bad"
option/argument users might end up inventing (doesn't seem that
createrepo in particular necessarily has any others, but I mean in general).

[Panu Matilainen]

Post by James Antill

Post by Ville Skyttä

Post by James Antill
Limit number of workers to 128 (should be enough for anyone :).

Sure, but out of curiosity, why?

Well if the user does --workers=666666 ... I think we can both agree
bad things will probably happen. You think the limit should be higher? I
picked 128 kind of randomly, although --workers=0 will still do it as
number of cores even if you have 1024 cores.

Since the point is to protect the innocent... I suspect 128 workers
would quite effectively kill a lowly single-core system anyway. Wouldn't
it be more useful to cap it based on the actual number of cores on the
system? Say, num_cpus_online() times two or four or thereabouts, to
allow testing multiple workers on non-SMP system but with a reasonably
safe upper limit.

Not that I actually care, just seems like a nice subject for bikeshedding :P

- Panu -