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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Apr 30 2003 - 22:00:28 EST