On Mon, 17 Feb 2025 at 11:08, Corinna Vinschen via Cygwin <cyg...@cygwin.com> wrote: > > On Feb 16 23:33, Lionel Cons via Cygwin wrote: > > On Sun, 16 Feb 2025 at 22:47, Mark Geisert <m...@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. Lionel
