Re: [RFD] Combined fork-exec syscall.

Mark Grosberg (mark@nolab.conman.org)
Sun, 27 Apr 2003 22:12:26 -0400 (EDT)


On Sun, 27 Apr 2003, Richard B. Johnson wrote:

> 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()

Actually, my original proposal will work for popen and all sorts of piping
because of the file descriptor map. For example:

int in[2], out[2];
char *null_argv[] = { NULL };
int fmap[4];
pid_t p;

pipe(in);
pipe(out);

fmap[0] = in[0]; /* STDIN */
fmap[1] = out[1]; /* STDOUT */
fmap[2] = open("/dev/null", O_RDWR); /* STDERR */
fmap[3] = -1; /* end */

p = nexec("/bin/cat",
null_argv,
NULL,
filmap);

In this case you save the extra closes the child would have to do and you
save the dup's.

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

Ahem, I happen to know Unix very well, thank you very much. Please read my
proposed API before flaming it out and assuming I know nothing of UNIX,
kernel development, or operating systems in general!

Do you honestly think that just because I picked a name spawn() that
happens to be in VMS (and MS-DOS C compilers) that I am inexperienced to
Unix. Nope. I just happen to be a BSD user in general and don't frequent
LKML.... and now I remember WHY!

And there _ARE_ issues this does solve as were already pointed out because
of the linear scan that must be made on the file descriptor array for the
close-on-exec flag (which this API could happily say it ignores since it
builds a _WHOLE_NEW file descriptor array).

L8r,
Mark G.

-
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/