[lkml]   [2003]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFD] Combined fork-exec syscall.

On Sun, 27 Apr 2003, Davide Libenzi wrote:

> 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

I guess it depends on what is considered saving. To be honest, my area of
interest is embedded systems. uClinux might benefit from such a syscall
(not that I have much experience with Linux on mmu-less hardware).

The idea would be to avoid the syscalls needed. I looked at the typical
fork-exec code I write and it does something similar to:

if (fork() == 0)
for(i = 3; i < NFILES; i++)



The system call I was proposing would have a few benefits:

(1) Because of the file mapping array that can be provided, the
closing of the file descriptors isn't necessary (close-on-exec
isn't always convenient to use). Neither is the dup()ing of
file descriptors for things like pipelines.

(2) There is always the difficulty of finding out in the parent
if the exec() fails. Sure you can stat the path, sure you can send
a signal or do this countless other ways. But the single syscall
would make this a no-brainer.

(3) We would eliminate the page faults for the new stack as the child
runs to setup the environment. I guess this could save a a few free
pages for a millisecond. Yeah, minor... but if you have a large
system with 1000's of users it may matter.

Of course, a new system call is intrusive in the kernel. One option is to
prototype this as a library function first, see how much use it gets and
then decide later on to move it to the kernel.

Mark G.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:35    [W:0.176 / U:2.172 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site