This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin 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: 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/


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