Re: [gentoo-dev] has_version etc parallelisability

[Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk>]

[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]

On Fri, 4 Jan 2008 18:50:56 -0800
Brian Harring <ferringb@gmail.com> wrote:
> Depends on the implementation; for pkgcore, if that comm pipe is 
> dead, the ebuild env *should* be dead, or dieing.  Background'ing 
> 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 '>=app-misc/foo-1.23' ; } &
}

> If you're refering to an ebuild that parallelizes itself while 
> executing, iow, parallelization w/in the ebuild env/phase execution, 
> 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()
{                                                                   
    portageq match ${ROOT} cat/some-pkg | while read a ; do
        if has_version ="${a}" ; then
            echo "yes to ${a}"
        else
            echo "no to ${a}"
        fi
    done                                                                        
}

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.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]