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 <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.
Patches welcome. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
