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
