On 3/5/2024 2:42 PM, Dan Shelton via Cygwin wrote:
On Mon, 4 Mar 2024 at 07:45, Mark Geisert via Cygwin <cygwin@cygwin.com> wrote:
On 3/3/2024 7:27 PM, Dan Shelton via Cygwin wrote:
[...]
strace does not help, as I need the Win32 calls BELOW posix_spawn(),
to see the implementation details.
Check the source code, then. It's at:
https://cygwin.com/cgit/newlib-cygwin/tree/winsup/cygwin/fork.cc
Look at line 587; there's the static function dofork(). Look at the
thirty or so lines above that; there's both fork() and
__posix_spawn_fork() calling dofork(). So both those user-level
functions call into the exact same internals. (BTW __posix_spawn_fork()
is called from posix_spawn(); the latter is in newlib and not Cygwin.)
You can even see the reason it's done this way by reading the comment.
Yes, but it is as I feared, Cygwin posix_spawn() does not use Win32
spawn() at all, and instead uses a rather inefficient vfork()
solution.
Cygwin's vfork() is just a wrapper around fork(), so yes. But anyway...
posix_spawn() was added to POSIX so a Win32 implementation can use Win32 spawn()
...now I see what you're getting at:
If posix_spawn() is intended to launch truly unrelated processes, with
minimal or no coordination with the launching process, why can't it just
use Windows' CreateProcess? I assume here that's what Win32 spawn() does.
That's an interesting research question for somebody. If somebody steps
up for that, great, otherwise as usual PTC.
Regards,
..mark
--
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
