On Thu, Sep 14, 2023 at 11:31 AM Ludovic Courtès wrote:
>
> Hi!
>
> "Thompson, David" skribis:
>
> > I'm curious to hear more about your inter-process transport needs!
>
> I’d like to have actors running in separate processes on the same
> machine. I wouldn’t want them to communicate over Tor
Simon Tournier skribis:
> IIUC, the current two “builder” backend are:
>
> + local ’guix-daemon’: the queue of derivations is processed using one
>strategy – the one implemented in C++,
>
> + ’cuirass remote-server’: the queue of derivations is processed using
>another strategy –
Hi!
"Thompson, David" skribis:
> I'm curious to hear more about your inter-process transport needs!
I’d like to have actors running in separate processes on the same
machine. I wouldn’t want them to communicate over Tor or TCP+TLS;
rather, I’d like them to use AF_UNIX sockets, “abstract
Hey Ludo,
On Wed, Sep 13, 2023 at 5:08 PM Ludovic Courtès wrote:
>
> With this actor split, one could implement another “builder” backend,
> for instance one that talks to a Build Coordinator process. It’s also
> obviously close to the programming model encouraged by Goblins, which
> should
Hi,
It is really cool! :-)
On Wed, 13 Sep 2023 at 23:08, Ludovic Courtès wrote:
> - The "builder" spawns derivation builds. There are currently two
> implementations: the local builder sends build requests to the local
> 'guix-daemon' process, while the remote build delegates builds
Hello Guix!
My (useful? misguided? questionable?) quest around Cuirass has led me
closer to some of the goals mentioned in my previous message¹ and in the
‘TODO’ file².
The ‘wip-actors’ branch³, which I plan to merge soon, splits activities
of the ‘cuirass register’ process among several actors.
