Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Run daemon on a server or in a different container #11

Open
mverleg opened this issue Apr 15, 2021 · 1 comment
Open

Run daemon on a server or in a different container #11

mverleg opened this issue Apr 15, 2021 · 1 comment

Comments

@mverleg
Copy link
Collaborator

mverleg commented Apr 15, 2021

It should not be very hard to make the daemon run on a server and have the CLI connect to it remotely.

This may be useful in a compiler-farm setup, or in a CI pipeline where a build-container keeps a continuous cache.

Some things that'd need to be addressed:

  • Lockfiles and stopping daemons would be more limited, probably without ability to kill unresponsive daemons.
  • Source file content needs to actually be sent to the daemon, with a clever way to send only unknown files.
  • Add a command to connect to a remote daemon, which'd be used instead of start. Also similar flags for build etc.
  • Should the run subcommand run locally or remotely? (Probably local)

For now let's not include having multiple daemons with a load balancer, though it might be possible one day.

@mverleg mverleg changed the title run daemon on a server or in a different container Run daemon on a server or in a different container Apr 15, 2021
@mverleg
Copy link
Collaborator Author

mverleg commented Apr 15, 2021

It'd also be useful for sharing a daemon between container and host OS.

But it may be a bit more tricky than I had thought. Some ideas:

  • Remote dependencies can be sent or downloaded, but either way they shouldn't change much
  • Whichever way is used to send source files do daemon: does it also work for non-source material? Ideally only compile-time things, like what is included by macros. Sending everything would be a big slowdown.
  • Should intermediary artifacts be sent back, or just final executable/lib?

The problem with non-code resources is actually not just the daemon - the compiler should also know about such things, to be able to rebuild when needed.

EDIT: The problem in general, and especially with non-source, is that one either 1) sends everything in a batch up-front, or 2) sends only what is needed, which means lots of back and forth communication, because it only becomes known gradually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant