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