[distcc] load management

[Dan Kegel]

Martin Pool wrote:
>>I don't think that's needed.  In fact, it's probably better if
>>the local server is connected to via a unix domain socket.
>>That's slightly faster and more secure.
>>Also, it lets us do tricky things like passing an open
>>socket from the local server to the distcc program,
>>so the bytes don't have to get relayed through the local server.
> 
> 
> I would slightly lean against that because it would not work on
> Windows.  I don't personally use Windows very often and supporting
> every feature of distcc there is not absolutely critical but I
> wouldn't break it lightly.

No problem; if it's not available, I'd fall back to actually
sending the bytes over the pipe.  I do want this to work on
Cygwin and Mingw eventually.

> I would be surprised if there was a significant speed difference
> between AF_UNIX and AF_INET at the rate of connections we're talking
> about here.

If fd passing is used, the speed difference might be noticable,
since it would completely eliminate one copy and a lot of task switching.

>>It even lets us pass credentials, so the local server could
>>even know for sure which unix user was making the request;
>>that could come in handy if we want to restrict status info
>>about jobs to the user who submitted the jobs.
> 
> Or you could just chmod the (directory containing the) socket. 

No, 'cause then I'd need a separate socket endpoint for each user,
and I'd have to worry about whether /tmp was writable
(it's not on one system I tried to install distcc on!).
I'd prefer to have a single server, installed by root
(not a problem in my environment, though I understand it'd
be a drawback in some places).

Your suggestion (in a separate note) of trying out fsh is interesting,
but fsh seems to also require the data to be sent via fshd,
which means one extra copy and one extra task switch per block.
Plus it's written in Python, violating the 'just c' policy of distcc.

I'd like to go for a world record time compiling e.g. the
linux kernel, so I'm a bit more worried about silly little
performance issues than is reasonable or healthy :-)
- Dan

-- 
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change