Subject: Re: posix_spawn facility
From: "gs-cygwin.com--- via Cygwin" <[email-masked]>
To: Bruno Haible <[email-masked]>
Cc: [email-masked]
Date: Thu, 20 Apr 2023 14:40:23 -0400
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>

On Thu, Apr 20, 2023 at 04:58:20PM +0200, Bruno Haible via Cygwin wrote:
> Corinna Vinschen wrote:
> > > Hmm.  Your code uses lpReserved2 for that, but the functionality is
> > > one implemented in MSVCRT.  For obvious reasons, Cygwin executables
> > > are not linked against msvcrt.dll and we're using lpReserved2 for our
> > > own purposes.
> > 
> > Oh, btw., did you know that there's a newer mechanism for defining
> > specific inheritable handles to CreateProcess, which is implemented
> > in kernel32.dll, so it does not depend on MSVCRT?
> > 
> > There's a STARTUPINFOEX structure which allows to specify the 
> > additional handles.  See
> > 
> > https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-startupinfoexa
> > 
> > and the PROC_THREAD_ATTRIBUTE_HANDLE_LIST argument described in
> > 
> > https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute
> 
> Indeed, this appears to be a more "official" way to pass handles for fd ≥ 3,
> instead of lpReserved2 — albeit without associated 'flags'. Not sure how
> O_APPEND is handled then... (Note: O_APPEND behaviour is tested by
> gnulib/tests/test-posix_spawn-open2.c.)
> 
> I had seen this doc page, but thought it was irrelevant because the
> title is about "thread attributes", not "process attributes"...

Excellent (very technical) article on the subject:

Programmatically controlling which handles are inherited by new processes in Win32
https://devblogs.microsoft.com/oldnewthing/20111216-00/?p=8873

Cheers, Glenn

-- 
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