This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
RE: OT: possible project/research project
- From: "Gary R. Van Sickle" <g dot r dot vansickle at worldnet dot att dot net>
- To: <cygwin at cygwin dot com>
- Date: Wed, 20 Mar 2002 21:25:03 -0600
- Subject: RE: OT: possible project/research project
> 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/