WinAPI spawn() not used by Cygwin posix_spawn()? Re: [PATCH] Cygwin: Add spawn family of functions to docs

[Corinna Vinschen]

On Feb 17 19:06, Lionel Cons via Cygwin wrote:
> On Mon, 17 Feb 2025 at 11:08, Corinna Vinschen via Cygwin
> <cygwin@cygwin.com> wrote:
> >
> > On Feb 16 23:33, Lionel Cons via Cygwin wrote:
> > > On Sun, 16 Feb 2025 at 22:47, Mark Geisert <mark@maxrnd.com> wrote:
> > > >
> > > > In the doc tree, change the title of section "Other UNIX system
> > > > interfaces..." to "Other system interfaces...".  Add the spawn family of
> > > > functions noting their origin as Windows.
> > >
> > > re spawn() family: Cygwin posix_spawn() seems to rely on the rather
> > > inefficient vfork(), while Opengroup intended it to be an API to
> > > Windows spawn().
> > >
> > > Is there a technical limitation why Cygwin posix_spawn() cannot use
> > > WinAPI spawn() directly?
> >
> > The requirements of posix_spawn and their helper functions are so
> > that we can't easily fulfill them without doing the fork/exec
> > twist.
> 
> How did UWIN do that? I did ask around - Glenn Fowler of AT&T Research
> demonstrated a prototype of UWIN posix_spawn() before posix_spawn()
> was finalised by the Austin Group as Opengroup POSIX standard. So this
> IS possible, and because non fork() or page cloning has to be done it
> should be significantly faster than the
> fork()-and-throw-copied-data-away-at-exec() approach.
> 
> > See https://man7.org/linux/man-pages/man3/posix_spawn.3.html.> Windows CreateProcess() is not quite the same as Linux clone().
> 
> Here might be the misunderstanding:
> posix_spawn() is intended NOT to copy anything except the file
> descriptors and requested attributes, no memory pages and no
> whatsoever. Everything should be done on the caller's process side,
> nothing in the child process.

Patches welcome.


Corinna