On Thu, 9 Apr 1998, Jason Thorpe wrote:

> On Fri, 10 Apr 1998 00:31:14 +0100 (BST) 
>  Sean Witham <Sean.Witham@asa.co.uk> wrote:
> 
>  > Would a better long term option be to implement a forkexec() atomic
>  > system call which someone else mentioned ? I'm not against a well
>  > documented vfork. I just wondered what people thought of the atomic
>  > fork and exec system call.
>  > 
> I don't think so, no... for a few reasons:
> 
> 	(1) No other UNIX-like system has that.

This hasn't stoped things before but I agree it would be better if the
idea was accepeted by otehr unix versions, at least the BSD4.4 based
ones if not otehr such as linux.

> 	(2) vfork(2) is actually documented in a standard now.
> 

Which came about because it was implemented by berkley despite the
fact it was unique to their release and was not implmeneted on the
AT&T tree.

> 	(3) vfork(2) is an "expected" interface for this sort of thing.
> 

I didn't suggets to remove vfork (at least in the short to medium
term). If you don't establish a more acceptable alterntive vfork will
be the only option. 

> 	(4) It makes decoding the error in the parent slightly more
>           difficult.
> 

I'm not a kernel hacker but as simple programmer I don't see the
problem yet (ignorance is bliss). As I see it an atmoic forkexec would
return with the same exit codes as the fork command. There would be
the combined errno's of fork and exec to check to determine why it
failed. It seems seems simple and more logical from user/programmers
point of view (well mine anyway).

Is it not worth pursuing the idea because of what has gone on before ?

--Sean