This is the mail archive of the cygwin-developers@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: vfork implementation


On Wed, Jul 28, 1999 at 12:03:39PM +1000, Trevor Yann wrote:
>The process information must be that of the child process. This includes
>the pid, parent process pid, process group id and file handles.

As I mentioned, the process information would not be too difficult to
get right.  I'd forgotten about file handles, though.  They will be
tricky, or possibly even impossible to get 100% correct.  This will be a
serious issue with shells.

>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.

Yup.

>There has to be special handling of exit (and _exit) as well.

Which is already done but more is needed.

>Multithreading is also a problem. I think that if we know that multiple
>threads exist, that we should drop back to fork().

I don't think that we have to worry about multi-threading.  If someone mixes
multi-threading with vfork, then they'll have to figure out the ramifcations
themselves.

>If a vfork implementation is added for B21, then I would like it to be a
>non-default option.

Unless the vfork implementation is very close to a standard implementation
(which mine isn't, currently) it can't be the default.  Currently vfork
just defaults to calling fork.  I guess, I will just turn off my stuff for
now.  I don't have the time to go much further with this but it was an
interesting exercise.

cgf

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]