bug#32980: [PATCH 0/2] Multiplexed build output from the daemon

[Ludovic Courtès]

Hello,

Ludovic Courtès <address@hidden> skribis:

> The downside of the protocol is that it creates quite some overhead.  For
> example, when extracting a tarball, we see things like:
>
>   read(13, "gmlo\0\0\0\0", 8)             = 8
>   read(13, "5\0\0\0\0\0\0\0", 8)          = 8
>   read(13, "@ build-output 25935 29\ncoreutils-8.29/m4/fseterr.m4\n", 53) = 53
>   read(13, "\0\0\0", 3)                   = 3
>
> That is, a 29-byte message with a 24-byte header (plus the
> 8 + 8 + 3 = 19 bytes of the underlying protocol; see ‘process-stderr’.)

I timed “guix build -S binutils --check”, which includes the output of
“tar xvf” followed by “tar cvf”, and the timing difference is not
noticeable (of course the peak of CPU activity is caused by xz.)

Anyway I went ahead and pushed this as
f9a8fce10f2d99efec7cb1dd0f6c5f0df9d1b2df.

I changed “@ build-output” to “@ build-log”, and also adjusted
tests/status.scm since new tests had been added to that file in the
meantime.

Ludo’.