On 2/5/06, Martin Pool <[EMAIL PROTECTED]> wrote: > You could combine it with the (currently disabled?) code that feeds the > compiler from a fifo, so as to stream back errors or terminate > compilation in the case of errors before the client finishes sending.
Gee, I didn't realize you could even do that. Don't compilers like to read the whole source before starting? > However I suppose failing files are fairly rare, since they will > generally terminate the build, and so not worth optimizing. I agree. The case I want to speed up is building correct files. > This will probably require changing the client to a nonblocking setup > where it can check for traffic back from the server while it keeps > sending. This is certainly possible, and will complicate it a bit but > perhaps not too much. I'll probably just pay the extra round trip for the moment to make the client change easier to code. I *have* been dying to rewrite all of distcc's networking to really use nonblocking I/O and to allow multiple simultaneous connections, but I'll continue resisting that urge as long as possible. > Incidentally, Van Jacobson's slides from linux.conf.au might be > of interest to you. It was a fascinating talk. > > http://www.lemis.com/grog/Documentation/vj/lca06vj.pdf > http://vger.kernel.org/~davem/cgi-bin/blog.cgi/2006/01/27#vj_channels Yes, indeed. Something for the future, though. > Will sending the hash first really be a problem? I would have thought > an extra round trip would be relatively cheap compared to the 2MB > transmission, but I'm not sure. I'm probably being overly perfectionistic. Benchmarking will reveal whether it's important. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv __ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc
