Random ideas for 3.7

[Jeremy Drake]

On Tue, 18 Mar 2025, Corinna Vinschen wrote:

> One of the biggies here is the way descriptor passing works in Cygwin.
>
> We're coming from a historical API model which didn't know the
> STARTUPINFOEX datatype, nor the UpdateProcThreadAttribute function
> and PROC_THREAD_ATTRIBUTE_HANDLE_LIST.  Thus, Cygwin is handling
> handles free-form.  Some handles required for Cygwin internally are
> simply inherited, FD_CLOEXEC is implemented by closing the handles
> in the forked child, etc.
>
> For posix_spawn without forking, this complicates matters.  For
> instance, we don't want having to close FD_CLOEXEC handles in the
> spawned child because that's a security problem.

Plus, the spawned process may not be Cygwin, so fixing this up in the
Cygwin startup code wouldn't catch that case.  Hmm, I had thought of some
of this, but I figured it already had to have been solved for spawn.  I
would have guessed FD_CLOEXEC handles would be marked as no-inherit, and
DuplicateHandle'd into forked children.  But I don't remember
PROC_THREAD_ATTRIBUTE_HANDLE_LIST either.  Good to know.