This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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, 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]