Messages in this thread | | | Date | Mon, 28 Apr 2003 12:07:01 -0700 (PDT) | From | dean gaudet <> | Subject | Re: [RFD] Combined fork-exec syscall. |
| |
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/
| |