scsh-users
[Top] [All Lists]

Re: fork vs. spawn

To: scsh@martigny.ai.mit.edu
Subject: Re: fork vs. spawn
From: Sean Doran <smd@chops.icp.net>
Date: 08 Aug 1996 02:56:17 -0400
-----BEGIN PGP SIGNED MESSAGE-----

wilson@cs.utexas.edu (Paul Wilson) writes:

> My understanding is that Scsh process control is based on UNIX-style
> fork(), which may be problematic for non-UNIX OS's

Well, yes, that's true, but to quote from the introduction
to the manual:

        This is a draft manual for scsh, a Unix shell that
        is embedded within Scheme.

and the reference paper is a really good rant about
everything wrong with UNIX, replete with many arguments
about why it would be much nicer if it had a good
scripting language.  

Other comments:

        The general systems architechture of Unix is
        cooperating computational agents that are realized as
        processes running in separate, protected address spaces,
        communicating via byte streams.  The point of a
        shell language is to act as the glue to connect up these
        computational agents.  That is the goal of scsh.
        ... Perhaps cooperating lightweight threads
        communicating through shared memory is a better
        way to live, but it is not Unix.  The goal here
        was not to come up with a better systems architechture,
        but simply to provide a better way to drive Unix.

I think that this pretty much says "fork you".  :-)

> I'd think that spawn could be more portable than fork.

It's not.

> Comments welcome.

While I would agree very quickly that there are some
deficiencies in scsh (it's _big_ comes to mind), and that
there are some obvious possible improvements, I think
firstly that scsh is currently incredibly useful and
secondly that it would not be substantially more useful if
Olin Shivers dropped some functionality and UNIXiness in
order to get it running on more platforms as a full- blown
development environment.

It may be that that kind of full-blown, portable
development environment would ultimately be more useful
to many people for many things, but "it's not UNIX".

I'd rather have Olin and company spend their cycles making
scsh more UNIXy (read that as: smaller, cheaper startup :) [*])
than on making it more portable, although that would mean
that some things on my wishlist would have to be done by
another tool altogether.

Of course, that's very UNIXy: one tool does not do
everything, which is why UNIX has lots of tools.

Mind you, looking at 4.4BSD's cat(1) manpage and
remembering that I'm occasionally spotted (and even admit
to) running emacs to read email and news, maybe I'm being
a bit hypocritcal. :-)

        Sean.

P.S.: Footnote:

[*] : chops.icp.net ; ps l
  UID   PID  PPID CPU PRI NI   VSZ  RSS WCHAN  STAT TT       TIME COMMAND
 3005  1581   396   1  10  0   836  176 wait   S+   p0    0:17.38 /bin/rc -i 
 3005 22259  1581   0   2  0 18532  464 select S    p0    8:43.94 emacs 
 3005 23524  1581  19  10  0 16568  340 wait   S    p0    0:01.49 scsh -o /usr/l
 3005 23525 23524   1  10  0   416  124 wait   S    p0    0:00.10 sh 
 3005 23526 23525   3  18  0   404  180 pause  S    p0    0:00.16 -sh (csh)
 3005 23527 23526   6  10  0   184  236 wait   S+   p0    0:00.11 rc 

What is wrong with this picture?

(For extra points, spot the two processes which have
actually been used to run more than one child process :) )

(For extra extra points, name the author(s) of each of the
shells, and list his, her or their crimes against humanity. :) )

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: PGP Public Key in ftp://ftp.sprintlink.net/engineer/smd/pgpkey

iQCVAwUBMgmPOESWYarrFs6xAQHVSwP+KXO/7y6pbErazYrCsKZ3NLoVjdHyZC6I
MnqiN/v364//IzpHuBLt8NQqIYG6/ayrxiLspI3AFsfXFSi0GDm77P7Smq2rz53g
Ljd6XYBt6rXmY2i25FvllRiUgWYDXSaanNljEoUS/UzpnJZVHgoovUDSJSJcFkR/
MpoR3pR6gdc=
=89pL
-----END PGP SIGNATURE-----

<Prev in Thread] Current Thread [Next in Thread>