On Sun, 27 Apr 2003, Mark Grosberg wrote:
> 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.
"expensive syscalls" are a mistake of non-linux unixes :)
> 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.
it's no more syscalls than are already required to set up stdin, out, and
error... the open() calls replace dup2() calls.
if the path walking is a problem then create a openparent(int parent_fd)
syscall... which would have to do all the same permissions checking that
using an open("/proc/ppid/...") would.
note that for this to be generically useful for CGI you also need to be
able to setuid(), and chdir(). this is why NT CreateProcess has a zillion
arguments -- and why it's really suspect...
-dean
-
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:30 EST