Gentoo Archives: gentoo-dev

From: Ciaran McCreesh <ciaran.mccreesh@×××××××××××××.uk>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] has_version etc parallelisability
Date: Sat, 05 Jan 2008 04:55:31
Message-Id: 20080105045212.7eebb1dd@snowcone
In Reply to: Re: [gentoo-dev] has_version etc parallelisability by Brian Harring
1 On Fri, 4 Jan 2008 18:50:56 -0800
2 Brian Harring <ferringb@×××××.com> wrote:
3 > Depends on the implementation; for pkgcore, if that comm pipe is
4 > dead, the ebuild env *should* be dead, or dieing. Background'ing
5 > processes from that env isn't valid imo, either.
6
7 Right. Paludis will give a weird die message but not actually fail if
8 you do:
9
10 src_compile() {
11 { sleep 10 ; has_version '>=app-misc/foo-1.23' ; } &
12 }
13
14 > If you're refering to an ebuild that parallelizes itself while
15 > executing, iow, parallelization w/in the ebuild env/phase execution,
16 > I'd look more at being able to batch commands instead of trying to
17 > run them in parallel.
18
19 That's its own slippery slope. Because of limited size pipes, the
20 following causes allllll sorts of trouble:
21
22 pkg_setup()
23 {
24 portageq match ${ROOT} cat/some-pkg | while read a ; do
25 if has_version ="${a}" ; then
26 echo "yes to ${a}"
27 else
28 echo "no to ${a}"
29 fi
30 done
31 }
32
33 The problem is thus: the has_version and portageq match here can be run
34 in parallel by bash. The portageq match output can be longer than the
35 maximum size of a pipe. Thus, if the above is legal, no lock that is
36 visible to the has_version can be held by portageq match once it starts
37 producing output.
38
39 --
40 Ciaran McCreesh

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-dev] has_version etc parallelisability Luca Barbato <lu_zero@g.o>