bug#30948: [PATCH core-updates] guix: Reap finished child processes in build containers.

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>>> My view is just that this mechanism belongs in “user code”, not in the
>>> low-level mechanisms such as ‘build-expression->derivation’ and
>>> ‘gexp->derivation’.  It’s a matter of separation of concerns.
>>
>> Why?  On my Guix System, such signal handling is handled by Shepherd, if
>> I'm not mistaken.  As I user, I can trust the foundation to be sane,
>> rather than having to provide the bits to make it so myself.
>>
>>> Of course we don’t want to duplicate that code every time, but the way
>>> we should factorize it, IMO, is by putting it in a “normal” module that
>>> people will use.
>>>
>>> Putting it in gnu-build-system is an admittedly hacky but easy way to
>>> have it widely shared.
>>
>> I think we can do better than hacky here :-)
>
> I think the real issue here is semantic clarity when it comes to
> derivation inputs.
>
> If I write:
>
>   (gexp->derivation "foo" #~(mkdir #$output))
>
> I can be sure that my derivation depends on nothing but (default-guile).
> This is important for tests, but also to make sure we can use this
> primitive everywhere—if it pulled in the Shepherd, I wouldn’t be able to
> use to build glibc, because there’d be a cycle.

I was not suggesting to pull in extra dependencies such as Shepherd, but
to weave the to-be-added signal handling logic at a much lower level.
One idea could be to arrange so that the correct signal handlers always
get installed for any Guile code running in the build side (I'm not sure
how, but perhaps by adjusting the gexp "compiler"?).

The handlers could be defined in (guix build signal-handling) or
similar.  Users wouldn't need to explicitly import the module and
install its signal handlers, that'd be taken care of automatically, all
the time.

Does that sound feasible?

-- 
Thanks,
Maxim