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.
-
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:28 EST