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"
> > >   https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/afdf1b68-1f3e-47f5-94cf-51e397afe073/cygwin-fork-and-rtlcloneuserprocess?forum=windowsgeneraldevelopmentissues
> > > 
> > > 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:
> https://cygwin.com/ml/cygwin/2015-04/msg00623.html
> 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?

BTDT.

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.


Corinna

(*) 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]