Re: [RFD] Combined fork-exec syscall.

[Davide Libenzi]

On Mon, 28 Apr 2003, Mark Grosberg wrote:

> The point of my system call is:
>
>   (1) Save the extra overhead of vfork() and exec(). A single system
>       call would still be faster.
>
>   (2) Avoid the resulting file descriptor manipulations for setting
>       up pipelines (dup's and closes).
>
>   (3) Avoid having to do any execution of the child. vfork() shares the
>       address space but there is still overhead in doing the setup of
>       vfork().

You still have to do a fork inside the kernel. For sure you don't want to
call do_execve() in the parent task context ;) So there's no save there.
Saving a few syscalls gives you almost nothing compared to the cost of
spawning a new process and to the machine resource consumption of the task
itself. The only place where this might have a measurable impact is when
you have the parent process with 100K fds open and still you have to have
a pretty short lived child process to have a measurable impact. Supposed
that this will be considered as worth, for sure you don't want to
introduce another syscall not respecting the POSIX one. That, if I did
read it correctly, sucks from that point of view. It suck because it is my
understanding that you have to explicitly drop close actions inside the
file actions list. So, suppose you have N fds and you want to close N-2
fds and dup 2 of them, you need N-2 close actions and 2 dup actions. So
you'll end up having an O(N) in user space to build the action list, and
at least an O(N) in kernel space to walk through it again. Actually, since
it is my understanding that the posix_spawn() interface assume an
all-fds-open by default, you have a few options to setup the child file
list :

1) You have an std clone() to copy all files to the new task struct
	( at *least* O(N) ) and you walk through the POSIX file action
	list to apply close/dup ( O(N) )

2) You have a special clone that starts with a brand new file table ( cost == 0 )
	and you walk though the old files array ( O(N) ) by seeking if the
	current file has actions passed by the caller. This is very bad
	since the action list is not indexed, so going in this direction
	w/out building some kind of index might be as O(N^2). Suppose you
	build an index that it'll give you an O(1), you still have to
	spend *at least* O(N) to build the index itself.

3) Other ways are possible but the minimum cost is at least O(2*N).

What would give the POSIX interface a boost would be to have a
default-all-closed option. In this case, in our example, we will have the
new process created with a blank file table ( cost == 0 ) plus 2 dups done
on the parent file table.

- Davide