This is the mail archive of the gcc-patches@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] pipe infrastructure support


On Tuesday, September 23, 2003, at 06:23 PM, Zack Weinberg wrote:
Mike Stump <mrs@apple.com> writes:

This adds piping infrastructure to libiberty for the compile server,
so that we can connect servers and local processes together,
arbitrarily.

This looks like a poor shadow of what I tried to do back in January. The patch was shot down for reasons which I consider completely bogus.

http://gcc.gnu.org/ml/gcc-patches/2003-01/msg02331.html

Better idea: get rid of collect2 it is a figment of our imagination that has outlived all usefulness. Once you do that, all these issues disappear, and the time waste that was fork and exec.


By this, I don't mean remove the functionality, I mean, have:

fork(exec(collect2("args")))

be replaced by:

collect2(arg1, arg2)

as in a normal C subroutine. This avoids all the issues that DJ doesn't like _and_ improves the portability of it. I'll do all this work at some point, just for the speedup we get from it, but I have other work that gets more (~2x) that I have to do first.

I intend to get this change into libiberty. I must have it for the compile server. Now, if someone rather that some of the code that is the most non-portable go into libiberty and sit behind nice APIs, well, I don't think that would be bad. But, at the limit, underneath it all, I have to have the fd for the pipe, no way around this.


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