Closed
Bug 866274
Opened 11 years ago
Closed 6 years ago
consider doing multithreaded repacking
Categories
(Release Engineering :: Release Automation: Other, defect, P3)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: bhearsum, Unassigned)
Details
We currently do repacks serially on a single machine. While they're mostly I/O bound, they still might get some benefit from doing 2 or more at the same time on a single machine. We should try this out at least, even if it doesn't pan out. If we do this we'll have to be careful when doing any build system operations that produce artifacts that aren't locale specific. We might need to use a semaphore or lock to avoid concurrency issues.
|
Reporter | |
Comment 1•11 years ago
|
||
A quick way to test whether this would be viable is to run two instances of the repack script in parallel on one machine. Also, this might not be worthwhile to do in create-release-repacks.py given the currently work going on to port all repacks to mozharness.
|
Assignee | |
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
|
|
Reporter | |
Comment 2•6 years ago
|
||
Might still be useful in a Taskcluster world? But things are fast enough now that it's unlikely to be worked on.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•