Random ideas for 3.7

[Corinna Vinschen]

On Mar 18 21:46, Corinna Vinschen wrote:
> 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.

...and even simplify FD_CLOEXEC if I didn't miss something.  This
might even speed up fork() slightly.

> 
> 
> Corinna