Re: [RFD] Combined fork-exec syscall.

[dean gaudet <dean-list-linux-kernel@arctic.org>]

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