[cs branch] how to start compile server?

[Mike Stump]

On Wednesday, August 27, 2003, at 05:23 PM, Ian Lance Taylor wrote:
> 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.

Yes, longer term, we may want to do this, but, for now, we can avoid 
all the security issues by using unix domain sockets that only the 
specific user that ran the compiler may communicate with.  This is easy 
to do, already done, and doesn't replicate much code.  Once we can 
accept data in from a TCP connection, we have to then spend _a lot_ of 
thought and work on the security model, as otherwise, we can then be 
responsible for the shut down of nuclear reactors and trains...  we 
aren't there yet, nor do we want to be.  The distcc project is the one 
that is managing connections, we don't want to replicate or handle 
anything that they solve.  They are the ones that needs the security 
model, the inetd wiring and so on.  We'll just use anything they do.

The compiler server project isn't so much about doing the server, as it 
is the infrastructure work to support a server.  Think of it this way, 
we want:

gcc -c foo1.c foo2.c foo3.c

to run one compiler and be fast and share information that can speed 
compilation across translation units.  There is no client, nor server 
here, just a shared database.  Now, later, I'd like to be able to move 
that database out to the second processor on a 2 CPU box, this requires 
locking, sharing and communications between two instances of the 
database on the CPUs.  After that, we want to move out the database 
farther, across users, across physical boxes and so on...  For now, we 
just use distcc and re-do the database for separate boxes.  Within a 
box, we don't even share, we will use two instances of the database and 
use CPU to re-create data, zero communication between the two.

I reviewed what xinetd brings, and it doesn't bring anything that we 
ever intend to solve, we'll except maybe managing starting up and 
sharing at most 2 servers, plus, it didn't look like it would manage 
unix domain sockets?

We only support unix domain sockets, so that we can have the more 
natural user interface:

gcc -c foo1.c
gcc -c foo2.c
gcc -c foo3.c

not for any other reason.