linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Richard B. Johnson" <root@chaos.analogic.com>
To: Mark Grosberg <mark@nolab.conman.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFD] Combined fork-exec syscall.
Date: Sun, 27 Apr 2003 22:09:37 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.53.0304272203570.14901@chaos> (raw)
In-Reply-To: <Pine.BSO.4.44.0304272036360.23296-100000@kwalitee.nolab.conman.org>

On Sun, 27 Apr 2003, Mark Grosberg wrote:

>
> Hello all,
>
> 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.
>
> L8r,
> Mark G.

You don't save anything but one system call time which is inconsequential
compared to the time necessary to exec (load a file, etc). Also, it is
worthless for anything except the most basic 'system()' or popen()
enulation. In fact, it wouldn't even work for popen() because one
needs to set up a pipe in the child before the exec.

All it does is add kernel bloat and duplicate existing kernel code
(both). Learn Unix instead of trying to make it VMS with spawn().


Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.


  parent reply	other threads:[~2003-04-28  1:53 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-28  0:57 [RFD] Combined fork-exec syscall Mark Grosberg
2003-04-28  0:59 ` Larry McVoy
2003-04-28  1:16   ` Mark Grosberg
2003-04-28  1:36     ` Måns Rullgård
2003-04-28  1:45       ` Mark Grosberg
2003-04-28  1:49       ` dean gaudet
2003-04-28  1:59         ` Mark Grosberg
2003-04-28  2:27           ` Miles Bader
2003-04-28 19:07           ` dean gaudet
2003-05-01 13:14       ` Jakob Oestergaard
2003-04-28  1:17 ` Davide Libenzi
2003-04-28  1:28   ` Mark Grosberg
2003-04-29  2:01     ` Rafael Costa dos Santos
2003-04-28  1:41   ` Ulrich Drepper
2003-04-28  1:49     ` Mark Grosberg
2003-04-28  2:19       ` Ulrich Drepper
2003-04-28  6:59       ` Kai Henningsen
2003-04-28  1:35 ` dean gaudet
2003-04-28  1:43   ` Mark Grosberg
2003-04-28  3:44     ` Mark Mielke
2003-04-28  5:16       ` Jamie Lokier
2003-04-28  2:38   ` Davide Libenzi
2003-04-28  2:09 ` Richard B. Johnson [this message]
2003-04-28  2:12   ` Mark Grosberg
2003-04-28  2:42     ` Werner Almesberger
2003-04-28  6:35       ` Mark Grosberg
2003-04-29  2:47       ` Rafael Santos
2003-04-28  3:20         ` Werner Almesberger
2003-04-28 13:00     ` Richard B. Johnson
2003-04-28 13:22       ` Andreas Schwab
2003-04-28 13:57         ` Richard B. Johnson
2003-04-28 13:57           ` Andreas Schwab
2003-04-28 14:16             ` Richard B. Johnson
2003-04-28 14:38               ` Valdis.Kletnieks
2003-04-28 14:56                 ` Richard B. Johnson
2003-04-28 14:42               ` Andreas Schwab
2003-04-28 16:36       ` Mark Grosberg
2003-04-28 17:19         ` Davide Libenzi
2003-04-28 18:28         ` Craig Ruff
2003-05-06  2:48         ` Miles Bader
2003-04-29 18:50       ` Timothy Miller
2003-04-28  2:32   ` Werner Almesberger
2003-04-28  7:40 ` Mirar
2003-04-28 12:45 ` Matthias Andree
2003-04-29  1:05 ` Rafael Costa dos Santos
2003-04-28  1:19   ` Mark Grosberg
2003-04-29  1:29     ` Rafael Costa dos Santos
2003-04-28  3:03 Davide Libenzi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.53.0304272203570.14901@chaos \
    --to=root@chaos.analogic.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark@nolab.conman.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).