10 P<P0QQP0 2012, 06:28 P>Q Ted Unangst <[email protected]>: > On Fri, Mar 09, 2012, Frank Denis wrote: > > Hi Matthew, > > > > Good catch. I'm going to fix that. > > > > On Mar 9, 2012, at 10:54 AM, Matthew Dempsky <[email protected]> wrote: > >> I briefly looked over this code, and the diff looks good to me except > >> for one subtle FreeBSDism: memory writes done in a vfork(2)'d child > >> process will not affect the parent process. This is critical for how > >> FreeBSD's posix_spawn() propagates errors from the spawned child > >> process. > > I believe you may be able to just use rfork. If the parent waiting > behavior of vfork is abslutely ocritical, we can add it to rfork very > easily. I think that makes more sense than making userland jump > through hoops.
now this is intriguing. AFAIK, classical vfork was invented in earlier BSD to avoid expensive duplication of a parent process in case all the child does is launch of other executable. SysV solved it with CoW, BSD came up with vfork. Now, how come OpenBSD has vfork which does not work as the classic vfork, instead we can use rfork, which does what vfork is supposed to do?
