> The issue at hand though, is twofold: > 1) Minimise the changes needed to make a proxy for a program. I.e. > imagine if GCC and cc1plus.exe lived in-process. That would remove 2Mb > of disk IO for each compile. However the _only_ chance of getting such a > program proxied would be a minimalistic, non-intrusive approach, or > keeping a patched branch :[. > 2) Make the context saving and restoring as low-overhead as possible. > (if this is > spawn() + wait, there is no point). > > Rob
My thinking on this matter (and I've been cogitating about it for some time actually) takes a slightly different tack. My basic ideas for a "modernized sh" are: 1. Eliminate as much fork()ing as possible, ideally all of it. 2. Get some concurrency going. #1 is basically the same as what you propose, though I'm not sure I'm wild about the DLL idea; if everything's a builtin, why not just statically link? #2 I think could be a significant win even for Unix folk. Basically I'm thinking along the lines of a "pipelined shell", e.g.: # Why should this...: rm //a/bunch/of/files/out/on/a/super/slow/server/* # ...block this: gcc hello.c Obviously you're never going to be able to take advatage of all non-dependencies, but as a wise man once told me, "you can't win if you don't enter". -- Gary R. Van Sickle Brewer. Patriot. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/