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 |