From: Keith M. <kei...@us...> - 2010-11-17 14:41:42
|
On 17 November 2010 13:43, Tomi Ollila <tom...@ni...> wrote: > On Wed 17 Nov 2010 15:28, Peter Rockett <p.r...@sh...> writes: > >> I don't do BASH so I have no idea of the significance of any of this. >> Can you explain in words why fork() is so great? > > ... > > fork() without exec() can be used to spawn multiple copies of the same > process which then can provide services to requests without changing > the state of the (parent) process launched... when work done the child > process can just exit and system takes care of resource destruction. > In my shell script example there were 2 subshells executed, with all the > content that shell script has been created so far (functions, variables, > etc.) where one subshell provided information to the another to do some > work. That's indisputably a useful capability, but unavailable on Windows, (and hence MinGW), because Windows doesn't have a fork() compatible API. > exec() without fork() can be used (for example) in wrappers where some > special work is done before the program that was intended to be run > is executed. When that program gets run, it is the direct child of > the original process starting the wrapper. With POSIX semantics for exec(), yes, this is the case, but *not* with Windows. When a Windows process calls exec(), the created process is *completely* independent of the creator; it will run as a detached process in its own right, while the creator will simply appear to have terminated. Whatever process invoked the creator will resume as if the creator had simply finished; it will never know that the exec()ed child ever existed. > fork(), following some settings in child process, which then exec()'s > was used in my example first to change working directory to somewhere > else, then redirecting the output of the command to a file. Now neither > the parent nor the process exec()ed needed to do/know anything about > these maneouvers, and therefore could be designed to be more generic. This is the scenario which Peter originally described as a "dog's breakfast". What he is crucially overlooking is the "some settings in the child, before exec()", which in his alternative have to be performed in the parent, *before* the spawn() of the child; these settings damage parent context, and it is the gymnastics which must be performed to preserve that parent context which make Peter's alternative the *real* "dog's breakfast" solution. When these settings are established in the child, between the fork() and exec() calls, they do not interfere with parent context, so there is no need for the gymnastics. And all of this has already been explained, previously in this thread! -- Regards, Keith. |