Re: Anti-Ada FUD (rant)

[Peter Brooks <peter.h.m.brooks@gmail.com>]

On Monday, 23 September 2013 14:54:43 UTC+2, Bill Findlay  wrote:
> 
> It duplicates the parent program.  It should allow the program to be run to
> be specified as part of the fork.  Postponing that to a following exec
> imposes costs that are very often unnecessary, and it can lead to race
> conditions in establishing the new running program's context.
> 
No, it doesn't lead to race conditions because the fork creates two separate instances, each with its own context. What costs do you know of from a later exec? You can, if you wish, run two programs, on from each fork, you don't have to keep a previous version running.

If you want the same effect as a fork with an exec, it's easy to do, you simply do the exec the following statement and have the parent suspend. Actually, the man page for exec() recommends you do this and recommends leaving the exec too late.
> 
> 
> > What particular principles of software design does the mechanism violate?
> 
> Unnecessary coupling.
> 
Unnecessary? A program is always run from a context, with the single exception of init. It is highly unusual for a program to require none of its parents context (I/O programs usually find it handy to have stdin and stdout defined for one thing). So the coupling of a child to its parent makes complete sense. 

I'm not wishing to advocate Unix as a perfect solution, of course, though it's the best known so far. However, if I was going to design an OS from the ground up, in, ideally, Ada, to replace Unix, I'd certainly base it on fork/exec for processes.

That's why I'm asking, if there's a genuine reason why there's something wrong with fork/exec, I'm keen to know it, not as Unix bashing, but because I'd like to know what better solution there might be.