From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1O2751-0007G8-Ix for garchives@archives.gentoo.org; Wed, 14 Apr 2010 18:12:51 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 502C2E0934; Wed, 14 Apr 2010 18:12:45 +0000 (UTC) Received: from mail-pw0-f53.google.com (mail-pw0-f53.google.com [209.85.160.53]) by pigeon.gentoo.org (Postfix) with ESMTP id EC1CBE091B for ; Wed, 14 Apr 2010 18:12:27 +0000 (UTC) Received: by pwj10 with SMTP id 10so351099pwj.40 for ; Wed, 14 Apr 2010 11:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=Fp1UkuFQKQuQZKDxPwmR6kmXV89itfhr2nfCnFIJPRI=; b=NKYPmR6te8ieKKfcEGfvHjQ1mKXz5Qq68L32EB3mcm8G/uOZDix5D2CljSltN1kZg0 q72Vt5QoeRvOd5HWRx5Zci5wzsK2Dn7CR3vFArUbECB8WYj5ecVNHKiF4TyzsAMZypjE 4fpsYhpObe9OzkDSNo9t5DT7c/2eYsy5Gq6Kk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=cns9IloPzYfJuAnnx9O1ojnVMug7Spl9oi7ynfN0DRbYRlUc0sgrV/hpyHqR5EZv3j wxwhNZ+J7T2CHXubYf2qvxgt+AjY1WD4WCuepnHs5iOxMp4c0EwPOC1jTC22Mt/pyivE Wlp7bxCtMai5+lNAme/t6HBW0um7YEDCdWpZA= Received: by 10.115.39.8 with SMTP id r8mr7007621waj.228.1271268744327; Wed, 14 Apr 2010 11:12:24 -0700 (PDT) Received: from smtp.gmail.com (c-67-171-128-62.hsd1.wa.comcast.net [67.171.128.62]) by mx.google.com with ESMTPS id 21sm509083pzk.12.2010.04.14.11.12.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 14 Apr 2010 11:12:23 -0700 (PDT) Received: by smtp.gmail.com (sSMTP sendmail emulation); Wed, 14 Apr 2010 11:10:29 -0700 Date: Wed, 14 Apr 2010 11:10:29 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Multiple emerges in parallel (was: [RFC] RESTRICT=parallel for builds that can't be executed in parallel) Message-ID: <20100414181029.GC30025@hrair> References: <4BC52478.3020303@gentoo.org> <20100414074520.339dd0ed@pomiot.lan> <20100414061016.GA30025@hrair> <20100414162018.26e0524c@pomiot.lan> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HG+GLK89HZ1zG0kk" Content-Disposition: inline In-Reply-To: <20100414162018.26e0524c@pomiot.lan> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: 53e51e8b-d18f-49d4-af31-929de035e53f X-Archives-Hash: 89c999b839d3c376964f308b04b37aa4 --HG+GLK89HZ1zG0kk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 14, 2010 at 04:20:18PM +0200, Michaaa GGGrny wrote: > On Tue, 13 Apr 2010 23:10:16 -0700 > Brian Harring wrote: >=20 > > Running multiple emerges in parallel is already a bad idea. The=20 > > solution for that case is for the new/second emerge to feed the=20 > > request into the original emerge (or a daemon). >=20 > Although such solution will be useful in many cases indeed, there are > still many advantages of having few separate emerge calls running > in parallel. The examples you give are fine and dandy, but if done via parallel=20 emerge you can run into situations where PM 1 just added pkg A as a=20 dep for PKG B, and PM 2 is removing pkg A due to a blocker for pkg C. Running multiple emerge's in parallel is unsafe due to the fact=20 they've got two potentially very different plans as to what is being=20 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=20 dependency of pkg D for example). Yes you can get away with it occasionally, that doesn't mean it's=20 safe however. > The next thing is aborting merges. When running multiple emerges, > aborting one of them is as simple as pressing ^c. With daemon, we would > have to implement an ability of aborting/removing packages in runtime > -- and that would be another example of dependency tree mangling. Aborting merges is a very, very bad idea. Consider a pkg that has=20 dlopen'd plugins, and just went through an ABI change for that=20 interface. If you interupt that merge it's entirely possible you'll=20 get just the lib merged (meaning a segfault on loadup of the plugins),=20 or vice versa (old lib is still in place, but new plugins are there). Don't abort merges- that really should be effectively an atomic OP,=20 not interuptible. ~harring --HG+GLK89HZ1zG0kk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAkvGBRUACgkQsiLx3HvNzgcTHwCghDyFsd2jJuVZ1zcBRMxkHvZn broAn1TOFQHNgl8yg4H1RlP9/gs2u2+8 =5y3W -----END PGP SIGNATURE----- --HG+GLK89HZ1zG0kk--