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


I am no cygwin expert, or windows expert, but isn't the effort better
spent getting the cygwin fork/vfork to work faster?

Stephano Mariani

PS: Please do not fry me if this is a stupid suggestion or not possible
because of an obvious flaw, I simply fail to see why the source of the
problem is not being targeted.

> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On
Behalf
> Of Randall R Schulz
> Sent: Wednesday, 20 March 2002 1:15 AM
> To: Robert Collins; cygwin@cygwin.com
> Subject: Re: OT: possible project/research project
> 
> Robert,
> 
> This idea isn't really new. I remember people talking about it back in
the
> System 6, System 7 and 32v days, when programs were starting to get
> bigger,
> disks were still pretty slow, main store rather small and there was
not
> yet
> a copy-on-write fork(2) or a vfork(2). (Not to mention the meager
control
> flow in the pre-Bourne shell that used a sub-process to effect a
seek(2)
> on
> the standard input being interpreted by the shell running the
script!!!)
> 
> The problem is that you're creating a huge project that creates no new
> functionality and that has horrendous maintainence issues, as you say.
> 
> The library conversion idea is kind of a throwback to pre-Unix days or
to
> systems like VMS (if I recall and understand it properly). In these
> systems
> there were "blessed" commands understood by the command interpreter
and
> endowed with a more direct means of invocation. Other commands
required
> full sub-process creation.
> 
> I trust it's your intent that the user will see no obvious differences
in
> invoking these programs, but you may find full transparency harder to
> achieve than you expect. Will the full range of shell features be
> available
> to these specially integrated commands? Will you be able to pipe into
and
> out of them? Will they work within parentheses? In procedures? Will
you
> allow all shell features (pipes, say) are applied to arbitrary
> combinations
> of conventional and integrated commands?
> 
> In your example of a `backquote command` (which I prefer to invoke via
$(
> ... ) using BASH) you'd be exposed to any unintended side-effects
within
> the backquote command. Side-effects like file descriptor alterations,
> changes in signal dispositions, receipt of signals or exceptions
(expected
> or the result of a programming error).
> 
> The beauty of the fork/exec model with entirely separated programs
_is_
> their self-containedness and the complete independence and isolation
each
> of the programs gets from each other and from the program(s) that
invoke
> them. It is also nice in that it is a very simple programming model
for
> commands, both built-in and end-user-supplied, that run within it. It
is
> probably less platform-specific than a scheme that demands use of
> dynamically-linked / shared libraries.
> 
> The Unix shell and process model may be somewhat costly of computing
> resources (but only marginally so), especially as I said without
> copy-on-write behavior in the fork call, but that rather modest
down-side
> is more than made up for by independence, modularity, and
open-endedness
> of
> the scheme.
> 
> I can't see how all the work your idea implies just for the sake of
some
> incremental performance improvements is going to be worthwhile.
> 
> By the way, which shell will you do this for? BASH, TCSH, Ash? More
than
> one?
> 
> Please feel free to prove me wrong, of course.
> 
> Randall Schulz
> Mountain View, CA USA
> 
> 
> At 22:50 2002-03-18, Robert Collins wrote:
> >Just a curiousity...
> >
> >I've a mental concept I've been batting around for a while - about
how
> can
> >we drastically increase configure and related script performance on
> cygwin...
> >
> >AFAICT the largest performance issue is fork() and exec(). File
access is
> >quite fast, as is networking. Unix sockets are a go slow given Ralf's
> >testing :p but that's about it.
> >
> >So, what I'm thinking could be done is:
> >Create a new shell. For the most common current causes of
fork()/exec(),
> >make those commands internal. Specifically, make all expression
> evaluation
> >(such as `basename foo`) done in-process (i.e. C-style
> >code:{save_context();evalute (expression);pop_context(result);}, only
> >spawning commands where they are not internal. (Currently, AFAIK, ash
and
> >bash use sub-shells quite commonly).
> >
> >Now that would be a maintenance and coding nightmare - repeating lots
of
> >other folk's work, and having to get bug compatability as well.... no
> thanks.
> >
> >What if, instead of rewriting all those helper commands, we
> >*) Make each one into a library - ie cygshellbasename0.dll. - with a
> >well-defined interface (say execute (int argc, char **argv), AND no
ABI
> >changes!
> >*) Replace the current binary with a façade that uses the .dll.
> >*) in the shell, look for the library *before* calling the binary,
thus
> >saving a spawn()
> >*) Ideally, adapt an existing shell rather than starting new (I'm not
a
> >reinvent-ze-wheel) kinda guy.
> >
> >Now I imagine that if done _properly_ the upstream authors won't
object
> >too much to librarization, so the amount of code to be written is
> >significantly shrunk.
> >
> >I've not seen a specific project to accomplish this (in
> >google/freshmeat/sourceforge) - but I figure that cygwin is _such_ a
> prime
> >platform for it that if one exists, and I'd be repeating work, I'll
find
> >someone who knows it here....
> >
> >Anyway, this is (obviously) a long-term proposition, but if two or
three
> >folk from here would be interested in collaborating on such a
project...
> >
> >Cheers,
> >Rob
> 
> 
> --
> 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/




--
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]