Re: [Mingw-users] fork(),waitpid() and setpid()

[Peter R. <p.r...@sh...>]

On 17/11/10 14:41, Keith Marshall wrote:
> 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*

Hang on a minute!! What alternative is that? All I did was to post a 
question asking about the original motivation behind fork() because it 
wasn't clear to me. I haven't proposed any alternative? Please do not 
ascribe opinions to me that I have not put forward.

> "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!
For what it's worth, it seems that Ken Thompson, one of the original 
UNIX guys from Bell, spent some time at Berkeley in the 1960s and 
borrowed the fork concept (and apparently other things) from the 
experimental SDS940 monitor program. Having looked at some documentation 
from this project (scanned, manual typewritten pages!) from 1966, it 
appears the fork() was simply a means of obtaining concurrent execution; 
intriguingly, forked  SDS940 processes were able to share memory, 
something we now associate with only threads. (I think Tor hinted at the 
relationship with threads.) I am now suspecting that it's the exec*() 
family that is the add-on, not the fork() call. But I will try to track 
that down to my satisfaction.

P.