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

[Thomas S. <th...@ws...>]

> From: Peter Rockett <p.r...@sh...>


> 
> That said, I now suspect that the fork() call was never originally 
> intended as a means of launching a child process with a different image 
> (a la spawn) but as a model of concurrent computation: a sort of early 
> attempt at a thread. 

Well, fork()ed instances of the same program still compete as an
alternative concurrent processing style to threads. Systems like linux for
instance, were designed to make new process creation as lightweight as
thread creation on other platforms. One of the cases for such a model is
that programs can be designed to scale to run on multiple computers at the
same time instead of just smp boxes. Windows is lacking in this area.


> The enlightenment for me is that sometimes, it is desirable to do stuff 
> between the fork() and the exec*() - I have never seen any examples of 
> doing anything other than fork() immediately followed by exec*() in 
> books, etc. Hence my question.

Your are starting to figure it out. This "in between time" is where the
meat of much of the unix system logic takes place. Most of the security
model is based around fork -> change security configuration -> exec* as
processes descend from init. Also things like detaching from the foreground
(daemons / services), io redirection (single best concept of unix), and all
sorts of things use this in between time. Maybe you need some better books?
:)

> 
> So as a means of launching a (new image) child, fork() is a 
> round-the-houses method. But clearly there are other benefits to fork().

> Ultimately it's a judgement call, as with most engineering decisions.

there are way more things to get frustrated over than fork(). signals
perhaps?

-- 
www.thomasstover.com
NO CARRIER