Richard B. Johnson wrote:
>
>
>To save some processing time, most knowledgeable software
>engineers would use vfork(). This leaves the major time,
>the time necessary to load the new application into the
>new address space and begin its execution. This time could
>be tens of milliseconds or even hundreds if the application
>is on a CD, floppy, a disk that hasn't been accessed yet,
>or the network. In the usuall situation where processing
>must be performed between the fork() and the execve(), you
>can't use vfork().
>
>You can measure the time for a system call by executing
>getpid() or something similar. It is in the noise compared
>to the time necessary to execute a program. Further, we
>get to the situation where one can't even verify a supposed
>speed increase because the system call overhead is in the
>noise. Great, one can claim any improvement they want and
>it can't be verified. What will be verified, though, is
>the increase in size of the kernel.
>
>
>
>
So, you can't save any time _for_that_particular_process_ by speeding up
the fork. Granted. But that wasted CPU time could be better spent
working on some unrelated process that is not waiting on I/O.
-
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:32 EST