Re: [RFD] Combined fork-exec syscall.

[Mark Grosberg]

On Sun, 27 Apr 2003, dean gaudet wrote:

> the only time fork-exec is inefficient, given the existence of vfork, is
> when you need to fork a process which has a lot of fd.  and by "a lot" i
> mean thousands.

Depends at what level of optimization you are talking about. I consider a
syscall an expensive operation. The transition from user to kernel mode,
the setup and retrieval of parameters all cost (and some architectures are
worse at it than i386).

> but even this has a potential work-around using procfs -- use clone() to
> get the vfork semantics without also copying the fd array.  then open
> /proc/$ppid/fd/N for any file descriptors you want opened in the forked
> process.

That is still quite a few syscalls (and some path walking for each file
descriptor)... I was proposing to get around the syscall overhead which
on large multi-user systems (or webservers running lots of CGI) could be
significant.

Honestly, I'm not sure if it is necessary either. But I can think of a few
advantages (and people on the list have thought of more)... How do
MMU-less archs spawn processes? Do they always use vfork()?

L8r,
Mark G.