Re: Cuirass actors
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 or TCP+TLS; > rather, I’d like them to use AF_UNIX sockets, “abstract sockets”, pipes, > socketpairs—one of these local IPC mechanisms. > > My understanding is that there could be an ocapn “netlayer” based on > that. Does that make sense? Is this something you’re considering? Thanks for clarifying! Yes, we definitely intend to provide local IPC netlayers such as UNIX domain sockets. We actually have a test netlayer that uses UNIX domain sockets, so some of this work has already been done. - Dave
Re: Cuirass actors
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 – implemented in Guile relying on ZeroMQ (something >like steal of work, if I remember correctly). > > Is it correct? Yes. > The Build Coordinator also implements the other actors “channel > updater”, “evaluator”, etc., right? No. > From my rough understanding, the first aim of Build Coordinator is the > implementation of the “builder”. Is it correct? Yes. > My two questions are: > > 1. Is the Build Coordinator able to only process the queue of > derivations? (being a “builder” backend). And if yes, what is its > strategy for processing? Yes, you give it derivations and it builds them; as for what its scheduling strategy is, I don’t know! > 2. In this picture of actor model, would it make sense (or would it be > possible) to replace the “builder” actor from the Cuirass one to the > Build Coordinator one? Yes, that’s exactly the message I tried to convey. :-) Thanks, Ludo’.
Re: Cuirass actors
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 sockets”, pipes, socketpairs—one of these local IPC mechanisms. My understanding is that there could be an ocapn “netlayer” based on that. Does that make sense? Is this something you’re considering? Thanks, Ludo’.
Re: Cuirass actors
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 make eventual migration easier (and when that happens, if Goblins > provides an inter-process transport, we’ll no longer need the custom > “bridge” and we’ll be able to move actors from one process to another > much more easily.) We're obviously very excited by this development over at Spritely. :) I'm curious to hear more about your inter-process transport needs! - Dave
Re: Cuirass actors
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 to > 'cuirass remote-server'. [...] > With this actor split, one could implement another “builder” backend, > for instance one that talks to a Build Coordinator process. 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 – implemented in Guile relying on ZeroMQ (something like steal of work, if I remember correctly). Is it correct? The Build Coordinator also implements the other actors “channel updater”, “evaluator”, etc., right? From my rough understanding, the first aim of Build Coordinator is the implementation of the “builder”. Is it correct? My two questions are: 1. Is the Build Coordinator able to only process the queue of derivations? (being a “builder” backend). And if yes, what is its strategy for processing? 2. In this picture of actor model, would it make sense (or would it be possible) to replace the “builder” actor from the Cuirass one to the Build Coordinator one? Cheers, simon
