From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262599AbTD1BFZ (ORCPT ); Sun, 27 Apr 2003 21:05:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262620AbTD1BFY (ORCPT ); Sun, 27 Apr 2003 21:05:24 -0400 Received: from x35.xmailserver.org ([208.129.208.51]:41871 "EHLO x35.xmailserver.org") by vger.kernel.org with ESMTP id S262599AbTD1BFT (ORCPT ); Sun, 27 Apr 2003 21:05:19 -0400 X-AuthUser: davidel@xmailserver.org Date: Sun, 27 Apr 2003 18:17:58 -0700 (PDT) From: Davide Libenzi X-X-Sender: davide@blue1.dev.mcafeelabs.com To: Mark Grosberg cc: Linux Kernel Mailing List Subject: Re: [RFD] Combined fork-exec syscall. In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 27 Apr 2003, Mark Grosberg wrote: > Is there any interest in a single system call that will perform both a > fork() and exec()? Could this save some extra work of doing a > copy_mm(), copy_signals(), etc? > > I would think on large, multi-user systems that are spawning processes all > day, this might improve performance if the shells on such a system were > patched. > > Perhaps a system call like: > > pid_t spawn(const char *p_path, > const char *argv[], > const char *envp[], > const int filp[]); > > The filp array would allow file descriptors to be redirected. It could be > terminated by a -1 and reference the file descriptors of the current > process (this could also potentially save some dup() syscalls). > > If any of these parameters (exclusing p_path) are NULL, then the > appropriate values are taken from the current process. > > I originally was thinking of a name of fexec() for such a syscall, but > since there are already "f" variant syscalls (fchmod, fstat, ...) that an > fexec() would make more sense about executing an already open file, so the > name spawn() came to mind. > > I know almost all of my fork()-exec() code does almost the same thing. I > guess vfork() was a potential solution, but this somehow seems cleaner > (and still may be more efficient than having to issue two syscalls)... > the downside is, of course, another syscall. This is very much library stuff. I don't think that saving a couple of system calls will give you an edge, expecially when we're talking of spawning another process. Even if the process itself does nothing but return. Ulrich might be eventually interested ... - Davide