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.
