Re: Porting vfork()

Perry Harrington (pedward@sun4.apsoft.com)
Wed, 6 Jan 1999 14:48:33 -0800 (PST)


I think that the traditional sense of vfork() is more akin to the clone() call
with all of the special "hide me in my parents PID" options turned off.
Perhaps vfork() should simply be an alias to clone() with the appropriate flags
set?

Linus, any comments?

--Perry

>
> Greetings,
>
> In the commercial world we often must port software to any *nix that
> a customer chooses to run. I suppose this means that Linux has arrived :)
>
> As of late the "different" vfork() behavior in Linux is appearing as a
> porting problem more often than expected (by me).
>
> Of course vfork() is a minor issue and it is easily dealt with in application
> code... and one could make the argument that vfork() developers at Berkeley
> never intended that a vfork parent would come to have a dependency on
> memory modified by its child prior to exec, etc, etc...
>
> When it does happen the programmer usually inserts another #ifdef LINUX
> into code that otherwise would require no modification, folds his arms
> across his chest, and chants "I really do love Linux" 3 times.
>
> So, the question: is linux vfork() behavior annoying anyone else and is it
> worth fixing? (other than to eliminate its appearance in the BUG area of the
> Linux fork() man page ;)
>
> Regards,
> Reed,
>

-- 
Perry Harrington       Linux rules all OSes.    APSoft      ()
email: perry@apsoft.com 			Think Blue. /\

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/