This is the mail archive of the cygwin 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]
Other format: [Raw text]

Re: fast/native fork?

On Jan 21 12:50, Thomas Wolff wrote:
> Am 21.01.2018 um 11:56 schrieb Marco Atzeri:
> > On 21/01/2018 16:32, Jay K wrote:
> > > 
> > > I have some desire to discuss fork.
> > > I know it is an old and difficult topic.
> > > 
> > > I found this:
> > > 
> > >   "Cygwin fork and RtlCloneUserProcess"
> > >
> > > 
> > > NT has had fork since v1.
> > > The Posix subsystem used it.
> > 
> > If you look at the several Corinna's tentatives of having any info
> > on the Microsoft forum the problem is the lack of official documentation
> > of the details.
> > 
> > Without details no solution can be implemented that is guaranteed
> > to work on all existing and hopefully future version of Windows.
> > 
> > Cygwin can only use official external API and not hidden internal one.
> There was this mail from Microsoft, offering support in case Windows 10
> would raise console problems with cygwin:
> While this was particularly about the console, maybe this offer could be
> used for a request to provide official documentation of that system call, so
> it could then be used?


There already was an internal discussion between us Cygwin devs and
Microsoft devs back in 2012 to handle various aspects of a POSIX fork
implementation(*), which was fairly detailed.  This was triggered by
Windows 8 previews breaking fork on Cygwin due to a change in ASLR
behaviour.  We also asked for some minor provisions in the official
Win32 API(**) but the discussion petered out during the Windows 8
release with no further reply from the Microsoft side.


(*) E.g., when using RtlCloneUserProcess everything done on the
    kernel/ntdll level appears to work (reading/writing to file handles,
    shared memory is available, etc), but simple higher-level stuff like
    Windows console handles become non-functional.

(**) E.g., telling CreateProcess that, right now, we don't want ASLR,
     regardless of the executables dynamicbase flag, or allowing the
     parent to tell the created child exactly where to load DLLs.

Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: signature.asc
Description: PGP signature

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