In article <199608091218.NAA09337@deacon.cogsci.ed.ac.uk>,
Richard Tobin <firstname.lastname@example.org.UK> wrote:
>> In most cases, I'd think you could do just as well to use a spawn()
>Do you have a spec for spawn()?
No. I'm trying to figure out what the spec should be, so that it's
easily portable but still useful.
>For unix, the problem is that there is so much that you can do between
>the fork() and exec() - shuffling file descriptors, changing
>directory, (un)ignoring signals etc. Do you build all these in as
>arguments to spawn()?
Possibly, but the main thing is to identify the basic functionality
and identify which things are worth adding via extra arguments
>Of course, these were discussions of *replacing* fork()/exec() in
>unix. Your goal is less ambitious,
Right. Far less ambitious.
(Another poster didn't seem to notice that my original posting was
talking about faking spawn() on unix with fork() and exec() from
a little server process that just forks the things that need to
> but how much would you want to do?
One thing that would be good would be simple spawning of filter processes
that you can pipe together. Nothing fancy, just a filter.
>I would have thought that connecting pipes to the child's stdin/stdout
>was necessary, but how do you do that if:
>> you could have a little parent process that you ask to fork copies
>> of itself when you want to spawn.
I'm not clear on why this is hard. It might require a kludge to
communicate the stdin to the spawnee, and record its stdout for
piping to the next spawnee.
>Given vfork() or copy-on-write fork(), implementing spawn()
>straightforwardly with fork() and exec() (rather than a helper
>process) is not as expensive as it used to be for large processes.
This is my understanding, too. So doing it efficiently on most
UNIXes may be trivial. It'd be less powerful than fork() and
exec(), but far more portable. And on UNIX, you'd still have
fork() and exec().
>Indeed, wasn't one of the original motivations for vfork() to make
>running processes from Franz Lisp cheaper?
I dunno. Sounds very plausible.
| 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/)