In <1404.107T1850T4774770rask@kampsax.k-net.dk> Rask Ingemann Lambertsen (rask@kampsax.k-net.dk) wrote:
> Den 06-Mar-00 16:29:18 skrev Rik van Riel fœlgende om "Re: Linux 2.2.15pre12":
>> Think about running a big simulation process that fork()s to
>> exec() /bin/mail in order to email its status or a partial
>> solution to the person that started the simulation.
>> A big rendering process that fork()/exec()s lpr.
>> Without overcommit you'd need to have the 500 MB of swap free
>> that the big simulation is using, even though it'll only use
>> 1 MB for the little process that's being exec()ed...
> This doesn't mean that overcommit is a good idea. It just means that
> fork()/exec() is not a good way of launching programs. Using overcommit to
> cover up for fork()/exec() deficiencies is like redirecting compiler
> warnings to /dev/null instead of fixing the code. The symptoms become less
> visible but the problem remains. The problem could be solved by introducing
> a new system call with the ability to start an external program as a new
> process.
And then we should start playing stupid games with file descriptors. And then
you can not spawn simple process to communicate with extenal program over net.
And my 20 apache processes will require 800MiB of virtual memory instead of
60MiB they are using now. Not every fork will end up with exec, you know. No,
fork()/exec() is RIGHT thing. And sometimes it's right thing to redirect
compiler warnings to /dev/null if compiler just not clever enough to find out
that warning is bogus. Replacing fork()/exec() with new system call a-la
WindowsNT looks like flu curing with guillotine.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:25 EST