In article <xoirapibbzi.fsf@chops.icp.net>,
Sean Doran <smd@chops.icp.net> wrote:
>-----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.
I've read the manual. (A while back.)
I realize that scsh's primary goal (at least right now) is to
be a good scripting language for UNIX.
I was trying to suggest a small concession to other OS's which
didn't seem damaging to scsh-on-UNIX.
>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.
> [ ... ]
>I think that this pretty much says "fork you". :-)
Not on my reading. I was *not* suggesting a move away from
the communicating-heavyweight-processes model.
>> I'd think that spawn could be more portable than fork.
>It's not.
Why not? Can't spawn be implemented in terms of fork, but
not vice versa?
On some UNIX platforms, I'd think spawn would be more efficient
than fork.
By the way, I was *not* slamming scsh. I *like* scsh.
I am a co-designer and co-implementor of a portable Scheme
system, RScheme and I'd like to support scsh.
Having a very portable subset of scsh (that works on non-UNIX)
seems generally desirable. I'd also like to support full-blown
scsh on UNIX.
What I was trying to establish was whether it would be *difficult*
to support a basic subset scsh on other platforms than UNIX.
I am not asking anybody to commit much effort to it. If it's
pretty trivial, I might suggest it, or we might hack it when
we get around to scsh support.
>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".
That's okay by me. I understand the goal of making a full-power
UNIX programming environment. But does that exclude the
possibility of a useful portable subset?
>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.
I was thinking that spawn might help with the size thing, on
some platforms. You don't need to copy the scsh process's
virtual address space to fork a child process---you get the
spawn daemon to fork itself instead. (Maybe this doesn't
matter because all decent UNIXes will do an efficient virtual
copy. I don't know. I wonder about NT Posix mode... crummy
fork sounds like just the kind of thing Mr. Bill might do
to sabotage UNIX.)
--
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (wilson@cs.utexas.edu)
| Papers on memory allocators, garbage collection, memory hierarchies,
| persistence and Scheme interpreters and compilers available via ftp from
| ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)
|