Random ideas for 3.7

[Corinna Vinschen]

On Mar 18 13:10, Jeremy Drake via Cygwin-developers wrote:
> On Tue, 18 Mar 2025, Corinna Vinschen wrote:
> 
> > Fodder for future Cygwin development:
> >
> > If you have other ideas what could be helpful for Cygwin, don't be shy
> > to add it to this thread.  Ideally with the intention to look into
> > implementing it by yourself, but at least a certain willingness to look
> > into the source code and discuss potential ways to implement it given
> > the current framework.
> 
> I periodically think about posix_spawn and the potential to fast-path
> simple cases to one of the spawn functions instead of a fork/exec.  This
> should give a relatively good effort to performance improvement ratio.

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.

An excellent preparation for a faster posix_spawn which spawns w/o
forking would be:

- Full handle bookkeeping.  Every single handle opened by Cygwin (not
  only those in an fhandler) is added to a list with the information
  if it has to be inherited by forked and execed/spawned children.
  And maybe more generic info, but that's not the point here.

- After having all handles booked in this central list, change
  frok::parent and child_info_spawn::worker to collect all handles
  to be inherited in a PROC_THREAD_ATTRIBUTE_HANDLE_LIST.

Incidentally this would not only simplify posix_spawn.  It would
catch the new FD_CLOFORK almost automatically.


Corinna