Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Multiple emerges in parallel (was: [RFC] RESTRICT=parallel for builds that can't be executed in parallel)
Date: Wed, 14 Apr 2010 18:12:51
Message-Id: 20100414181029.GC30025@hrair
In Reply to: Re: [gentoo-dev] Multiple emerges in parallel (was: [RFC] RESTRICT=parallel for builds that can't be executed in parallel) by "Michał Górny"
1 On Wed, Apr 14, 2010 at 04:20:18PM +0200, Michaaa GGGrny wrote:
2 > On Tue, 13 Apr 2010 23:10:16 -0700
3 > Brian Harring <ferringb@×××××.com> wrote:
4 >
5 > > Running multiple emerges in parallel is already a bad idea. The
6 > > solution for that case is for the new/second emerge to feed the
7 > > request into the original emerge (or a daemon).
8 >
9 > Although such solution will be useful in many cases indeed, there are
10 > still many advantages of having few separate emerge calls running
11 > in parallel.
13 The examples you give are fine and dandy, but if done via parallel
14 emerge you can run into situations where PM 1 just added pkg A as a
15 dep for PKG B, and PM 2 is removing pkg A due to a blocker for pkg C.
17 Running multiple emerge's in parallel is unsafe due to the fact
18 they've got two potentially very different plans as to what is being
19 done, and that there is no possibility to ensure that pkg D that PM-2
20 is building isn't affected by PM-1 building something (upgrading a
21 dependency of pkg D for example).
23 Yes you can get away with it occasionally, that doesn't mean it's
24 safe however.
26 > The next thing is aborting merges. When running multiple emerges,
27 > aborting one of them is as simple as pressing ^c. With daemon, we would
28 > have to implement an ability of aborting/removing packages in runtime
29 > -- and that would be another example of dependency tree mangling.
31 Aborting merges is a very, very bad idea. Consider a pkg that has
32 dlopen'd plugins, and just went through an ABI change for that
33 interface. If you interupt that merge it's entirely possible you'll
34 get just the lib merged (meaning a segfault on loadup of the plugins),
35 or vice versa (old lib is still in place, but new plugins are there).
37 Don't abort merges- that really should be effectively an atomic OP,
38 not interuptible.
40 ~harring