Native posix_spawn() in Cygwin?
Mark Geisert
mark@maxrnd.com
Fri Jun 7 05:08:48 GMT 2024
On 6/6/2024 4:09 PM, Dan Shelton via Cygwin wrote:
> On Wed, 6 Mar 2024 at 01:08, Mark Geisert via Cygwin <cygwin@cygwin.com> wrote:
>>
>> On 3/5/2024 2:42 PM, Dan Shelton via Cygwin wrote:
[...]
>>> 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.
>>
Kindly let me interject this first.
Could the implementor(s) of Cygwin's posix_spawn() possibly comment on
why it ends up doing a fork(), if I understand correctly, rather than
doing what Win32 (or even Cygwin's) spawn() does?
>
> I'm not sure, but I think this would benefit Cygwin greatly to
> implement a native posix_spawn(). It should be faster and scale
> better. Also the only stuff which do really need fork() are
> bash/dash/ksh, and maybe daemon stuff like sshd.
I think I remember back in the last century Cygwin's 'make' got some
attention because fork()s were judged to be slow during Cygwin's early
years. I don't know if the shells got the same attention then or since.
Somebody would have to look.
>
> Re CreateProcess: Maybe CreateProcess() breaks access token or newgrp support?
We prefer dealing with detailed bug reports as opposed to speculation :-)
That said, Cygwin does implement system(), popen(), and the spawn*()
family of functions that all launch subprocesses with CreateProcess()
rather than using fork(). Perhaps one of them would work for you?
>
> Does Cygwin do bounties (paid bug fixes), or Google Summer Of Code?
Not that I know of.
..mark
More information about the Cygwin
mailing list