Mail Archives: cygwin-developers/1999/07/27/22:03:08
I have been thinking about a vfork implementation for some time. I never
managed to get to an implementation, but the issues that I discovered
may be of interest.
The process information must be that of the child process. This includes
the pid, parent process pid, process group id and file handles.
The file handles are fairly tricky. I have seen vfork code that plays
with file handles, doing dups, closes and (rarely) opens. These changes
should apply to the actual child process (after the exec), but shouldn't
affect the parent process.
Signal handling may also be a consideration.
There has to be special handling of exit (and _exit) as well.
Multithreading is also a problem. I think that if we know that multiple
threads exist, that we should drop back to fork().
If a vfork implementation is added for B21, then I would like it to be a
non-default option.
Chris Faylor wrote:
>
> Ok. I've got an experimental vfork implementation working. I worked
> out most of it in the air between Boston and Sunnyvale last week.
>
> The way it works is to fill in a structure with some frame information,
> returning from vfork with a value of 0. The assumption is that the
> calling program will 1) not return from the function which called the
> vfork (which is true for the BSD vfork implementation) and 2) quickly
> call some exec function.
>
> When an exec function is invoked, it checks the above structure to see
> if the process is in a 'vforked' state and changes any exec to a
> spawn*(P_NOWAIT). The spawn* function then invokes the "execed" program
> as a subprocess and longjmps back to vfork, where the stack is fixed up
> and vfork returns with the pid of the newly execed process.
>
> If the exec* function fails, and the program exits, then a true fork is
> done which immediately exits with the exit value. The parent process
> then sees the pid of this process on return from vfork.
>
> This implementation has at least one problem. If you do a 'getpid()' in
> the child process you get the pid of the parent not the child. This is
> not insurmountable but I am wondering how big a problem this might be.
> Does anyone have any idea?
>
> In benchmarks, this vfork is *at least* twice as fast as a normal fork.
>
> So what do you think? Is this good enough to go into the mythical next
> net release (B21)? Should I make it a cygwin option, i.e.
> CYGWIN=fastvfork?
>
> cgf
- Raw text -