From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JB14F-00078g-Ei for garchives@archives.gentoo.org; Sat, 05 Jan 2008 04:55:31 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.2/8.14.0) with SMTP id m054sEe5010394; Sat, 5 Jan 2008 04:54:14 GMT Received: from smtp.ferdyx.org (170.Red-213-96-222.staticIP.rima-tde.net [213.96.222.170]) by robin.gentoo.org (8.14.2/8.14.0) with ESMTP id m054qIQc008070 for ; Sat, 5 Jan 2008 04:52:18 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.ferdyx.org (Postfix) with ESMTP id 668C98D306 for ; Sat, 5 Jan 2008 05:58:05 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at ferdyx.org Received: from smtp.ferdyx.org ([127.0.0.1]) by localhost (tungsteno.ferdyx.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TABMXdE+7o-m for ; Sat, 5 Jan 2008 05:58:03 +0100 (CET) Received: from snowcone (unknown [213.121.151.206]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ferdyx.org (Postfix) with ESMTP id 61A518D305 for ; Sat, 5 Jan 2008 05:58:03 +0100 (CET) Date: Sat, 5 Jan 2008 04:52:12 +0000 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] has_version etc parallelisability Message-ID: <20080105045212.7eebb1dd@snowcone> In-Reply-To: <20080105025056.GE5844@seldon> References: <20071230223519.48adc9be@snowcone> <20071231142844.5e2a09aa@snowcone> <20080105025056.GE5844@seldon> X-Mailer: Claws Mail 3.2.0 (GTK+ 2.12.1; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/koIukSvtwVvtr_GLf6GUF.u"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: bc1a2036-8060-4c2a-ae79-3c0bed298212 X-Archives-Hash: d8ca22fc6d89eafe9476cdfaa6a20f9a --Sig_/koIukSvtwVvtr_GLf6GUF.u Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 4 Jan 2008 18:50:56 -0800 Brian Harring wrote: > Depends on the implementation; for pkgcore, if that comm pipe is=20 > dead, the ebuild env *should* be dead, or dieing. Background'ing=20 > processes from that env isn't valid imo, either. Right. Paludis will give a weird die message but not actually fail if you do: src_compile() { { sleep 10 ; has_version '>=3Dapp-misc/foo-1.23' ; } & } > If you're refering to an ebuild that parallelizes itself while=20 > executing, iow, parallelization w/in the ebuild env/phase execution,=20 > I'd look more at being able to batch commands instead of trying to > run them in parallel. That's its own slippery slope. Because of limited size pipes, the following causes allllll sorts of trouble: pkg_setup() { =20 portageq match ${ROOT} cat/some-pkg | while read a ; do if has_version =3D"${a}" ; then echo "yes to ${a}" else echo "no to ${a}" fi done = =20 } The problem is thus: the has_version and portageq match here can be run in parallel by bash. The portageq match output can be longer than the maximum size of a pipe. Thus, if the above is legal, no lock that is visible to the has_version can be held by portageq match once it starts producing output. --=20 Ciaran McCreesh --Sig_/koIukSvtwVvtr_GLf6GUF.u Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHfwz+96zL6DUtXhERAiPOAKCRBv4xrFmEwECyCJDT1FTlBJIuXwCfeUaA 5GrRFGAo4XmEDyxyPzXpf68= =Y3P0 -----END PGP SIGNATURE----- --Sig_/koIukSvtwVvtr_GLf6GUF.u-- -- gentoo-dev@gentoo.org mailing list