In article <firstname.lastname@example.org>,
Sean Doran <email@example.com> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>firstname.lastname@example.org (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
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.
> 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.
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
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 (email@example.com)
| 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/)