| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|
|
|
|
|
| |
This should also fix bugs related to CompositeTask instances waiting
for queued tasks to start and not being properly terminated in this
case.
|
|
|
|
|
|
|
| |
This reverts behavior from bug #375331 (commit
f07f8386e945b48358c11c121960e4833c539752) for cases in which --jobs is
greater than 1. We can add a separate --fetch-jobs option later, but
for now, this preserves previous behavior for --jobs > 1.
|
|
|
|
|
|
| |
Since commit f07f8386e945b48358c11c121960e4833c539752, the first will
have to wait for later ones to fetch unless we start its prefetcher
first.
|
|
|
|
|
|
|
|
| |
Since the io module in python-2.6 was broken when threading was
disabled, we needed to fall back from io.StringIO to StringIO.StringIO
in this case (typically just for Gentoo's stage1 and stage2 tarballs).
Now that python-2.7 is stable in stages and we rely on io.open() being
available, we can also rely on io.StringIO being available.
|
| |
|
|
|
|
| |
This ensures that we account for EMERGE_LOG_DIR.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This should prevent FEATURES=parallel-install from interfering with
the fixes from bug #256616 and bug #259954.
|
|
|
|
|
|
|
|
| |
Use a separate queue for ebuild-locks when the merge
queue allows more than 1 job (due to parallel-install),
since the portage.locks module does not behave as desired
if we try to lock the same file multiple times
concurrently from the same process.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Narrow scope of merge locks to improve performance.
Instead of locking the DB for the entire package merge, just lock it
when we actually need to do so. Also add locks around conf_mem_file
updating and pkg_* phases.
Locking in pkg_* phases can be turned off with
FEATURES="no-ebuild-locks" if you use ebuilds that are careful not
to mess with each other during theses phases. The default is to leave
this locking enabled.
Given this new locking, I've improved the scheduler to run merge jobs
in parallel.
Time required for merging 348 packages with --usepkgonly:
- Before patch: 29m50s
- After patch: 10m2s
- After patch w/o locks: 7m9s
Change-Id: I63588c4cc59fa6fe2f8327ea1e4a9e71b241d4fe
Review URL: http://gerrit.chromium.org/gerrit/498
|
|
|
|
|
| |
Now all the virtual/libc handling is done by the depgraph, which
will be helpful when fixing bug #364681.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we are passed a fakevartree object, it should already be sync'd, so
there is no need to sync it again here. This sync is only needed when
we create a new FakeVartree, so I moved the sync to the right place to
fix this.
BUG=chromium-os:14035
TEST=Build a bunch of packages with this patch.
Change-Id: I89d79cf946f4c0c27ad585ad7c88a41985260342
Review URL: http://codereview.chromium.org/6813084
|
| |
|
|
|
|
| |
This clarifies the purposes of _system_merge_started and _choose_pkg.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, Portage syncs the BlockerDB before every merge. This slows
down merges considerably because it requires reading the entire vardb
from disk. Since Portage doesn't merge conflicting packages anyway, we
can optimize this by just reading the vardb at initialization and
caching that.
Change-Id: I6701926f022ef3aa2da10482fc8b09573ae24610
Review URL: http://codereview.chromium.org/6688037
|
|
|
|
|
| |
If we have running tasks, but we're not listening to these tasks,
we're going to loop forever. So throw an exception in this case.
|
|
|
|
|
| |
This should prevent "TypeError: an integer is required" raised from
waitpid when trying to cancel a prefetcher that never started.
|
| |
|
|
|
|
|
| |
Thanks to David James <davidjames@google.com> for reporting this error:
AttributeError: 'EbuildPhase' object has no attribute 'merge'
|
|
|
|
|
|
|
|
|
| |
* PollScheduler and all subclasses now use the _terminated_tasks
variable to check whether or not _terminate_tasks() has been called,
and behave appropriately in that case.
* The _schedule_tasks() method now has documentation about the
relationship with _terminate_tasks() and _terminated_tasks.
|
|
|
|
|
|
|
|
| |
If CTRL-C was received at certain times, it was possible for discarded
tasks to be erroneously left in Scheduler._running_tasks, which would
cause the main loop to run infinitely. Thanks to David James
<davidjames@google.com> for reporting this issue and helping to devise
a solution.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This allows PollScheduler instances to do basic cleanup and terminate
gracefully when SIGINT or SIGTERM signals are received.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This helps to avoid some cases in which emerge crashes due to ebuild
modification that leads to failure in aux_get/manifest check while
the Scheduler is running. Typically such modifications are harmless,
so it's beneficial to cache the metadata so that aux_get is less
likely to be called when it will fail.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|