This is the mail archive of the
mailing list for the GCC project.
Re: [cs branch] how to start compile server?
- From: Mike Stump <mrs at apple dot com>
- To: Ian Lance Taylor <ian at airs dot com>
- Cc: Per Bothner <per at bothner dot com>, GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: Thu, 28 Aug 2003 14:28:15 -0700
- Subject: Re: [cs branch] how to start compile server?
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,
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.