Re: [cs branch] how to start compile server?

[Ian Lance Taylor <ian at airs dot com>]

Andrew Pinski <pinskia@physics.uc.edu> writes:

> > The general notion of running a server is a well-understood one and
> > there is a lot of existing code to do it.  Recreating the code in gcc
> > itself seems mildly pointless.  Projects like tcpserver, xinetd, and
> > tcpwrapper exist to handle being a server.
> 
> {x,}inetd starts programs when connections open, which is what already
> happens now for the driver gcc.

I mentioned xinetd because what it really does is manage connections
coming in from remote systems, and, for that matter, from the local
system.  That is, xinetd is a server manager.  It provides a range of
degrees of control over incoming connections.  It's true of course
that it starts programs when connections come in.  But that does not
preclude using it with a gcc server; it just means that you need a
small helper program to feed the incoming connection into a running
gcc server.

> > Similarly, on the client side, I don't see any particular reason to
> > use gcc at all.  Instead, define a simple protocol--you've already
> > done this--and write separate programs to generate that protocol.  For
> > example, instead of `gcc -server', just use `gcc-server'.  That
> > separate program can then grow to take whatever options will be needed
> > to locate the server--using a URI naturally suggests itself.
> 
> Note that gcc is just a driver which starts programs much like what
> {x,}inet
> does.

I'm not sure quite what you mean here.  I would say that xinetd
controls and manages incoming network connections.  It is a server
manager.  This is quite different from gcc -server, which is a client
program, not a server program.

> So calling gcc -server tells the driver to go into client mode
> for the
> compiler server and use the server (without -server tells to use the
> normal mode
> and launch {cc1{,plus,objc},jc1,f771,ada?,f951}, the real
> "front-end"). This is much
> like what telnet or ssh does. Right now there is no such thing as a
> remote GCC server,
> it is all local compiling.  distc is what I think you are trying to
> describe which does
> compiling on other machines.

I understand that the compile server does not currently support being
used in a distributed mode.  However, it's an obvious future feature,
and Per mentions it as such in his paper.  I understand that that is
not the purpose of the compile server.

> > In general, though, I think it's desirable to keep the networking code
> > out of gcc proper, and I think it can be done without loss of
> > efficiency.
> 
> There is no networking code in GCC at all still.
> The compile server is more like the talk server which uses UNIX fifo's.

Well, Per's e-mail note, and his paper, clearly say that the compile
server uses Unix domain sockets.  That is networking code.  It's true
that Unix domain sockets only work on the local machine.  But it is a
tiny tweak to Unix domain code to use TCP sockets instead.

I'm suggesting that issues like how to communicate with the server be
moved out of gcc proper, to maximize flexibility and to take advantage
of existing programs.  My comments would actually still apply if your
were correct that the compile server used Unix FIFOs.

Ian