Hey, Paul.
What did you have in mind for a spawn procedure? Something like
(SPAWN file arg-vec fdes/port-vec [env cwd]) -> proc-obj
where
file: name of the binary file to execute.
arg-vec: string vector passed to childs argv.
fdes/port-vec: a vector of ports and file descriptors. Element i
of the vector is used to set file descriptor #i in the child.
#f elements in the vector are ignored (closed?).
env: process environment alist for child.
cwd: current working directory (string).
I'm probably leaving out some process state that you'd want to frob in
some cases (uid, gid, etc.). I'm probably including some state that doesn't
port outside of Unix. As I am not a non-Unix OS hacker, I am not really
competent to design a cross-OS portable SPAWN.
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.
Then the spawned child isn't the scsh process' child, so some system calls
won't work. Richard Kelsey had a very aggressive variant of this, where
you put *all* OS functionality in a little bitty process, and your big
Scheme process indirects all syscalls over to it. So fork is fast. I thought
this was cute, but think you'd better off fixing the problem (get scsh's
size down) instead of side-stepping it.
-Olin
|