[PATCH 4/5] Cygwin: add fast-path for posix_spawn(p)

[Sebastian Feld]

Was this work ever merged into Cygwin1.dll?

Sebi

On Thu, Jul 24, 2025 at 8:44 PM Jeremy Drake via Cygwin-patches
<cygwin-patches@cygwin.com> wrote:
>
> On Thu, 24 Jul 2025, Corinna Vinschen wrote:
>
> > On Jul  7 12:45, Corinna Vinschen wrote:
> > > On Jul  4 15:59, Jeremy Drake via Cygwin-patches wrote:
> > > > On Fri, 4 Jul 2025, Jeremy Drake via Cygwin-patches wrote:
> > > > > On Fri, 4 Jul 2025, Corinna Vinschen wrote:
> > > > > > I see what you mean.  The question of questions is if "as if" only
> > > > > > covers the "performed exactly once" requirement, or if the "as if"
> > > > > > really encompasses all three requirements, i.e.
> > > > > >
> > > > > > - as if the specified sequence of actions was performed exactly once
> > > > > >
> > > > > > - exactly in the context of the spawned process (prior to execution of the new
> > > > > >   process image)
> > > > > >
> > > > > > - exactly in the order in which the actions were added to the object
> > > > > >
> > > > > > in contrast to
> > > > > >
> > > > > > - as if the specified sequence of actions was performed exactly once
> > > > > >
> > > > > > - as if in the context of the spawned process (prior to execution of the new
> > > > > >   process image)
> > > > > >
> > > > > > - as if in the order in which the actions were added to the object
> > > > > >
> > > > > > My understanding (as a non-native speaker) is that "as if" only
> > > > > > covers the "performed exactly once" requirement.  Applying "as if"
> > > > > > to the order requirement doesn't make much sense to me.  And applying "as if"
> > > > > > implicitely to the second requirement, but not to the third, doesn't
> > > > > > make much sense to me either.
> > > > >
> > > > > The "as if" performed exactly once doesn't make a whole lot of sense to me
> > > > > either... To me, the only case where "as if" adds flexibility is the
> > > > > context of the child process.
> > > > >
> > > > > > On top of that you'd have the problem that the man pages of
> > > > > > osix_spawn_file_actions_addclose and posix_spawn_file_actions_addchdir
> > > > > > contradict each other.  This, of course, is always possible.  Only an
> > > > > > RFC to the Austin Group could clarify this.  Maybe we should really do
> > > > > > that.
> > >
> > > https://austingroupbugs.net/view.php?id=1935
> >
> > Good news:
> >
> > https://www.austingroupbugs.net/view.php?id=1935#c7229
> >
> > I'm glad I asked.
> >
> > tl;dr: The Austin Group just changed all the descriptions in terms of
> > posix_spawn_actions, so that they are to be performed *as if* they
> > are running in the child preior to calling execve().
> >
> > This means, we're free to run alkl desired actions in the parent, as
> > far as that makes sense.
> >
> > I still think it might make sense to run some of the actions in the
> > context of the child's child_info_spawn::handle_spawn() processing,
> > but we can restart discussing this as we go along.
> >
>
> Great!  I rebased the topic/posix_spawn branch yesterday to use a local
> child_info_spawn instance, but otherwise haven't really been looking at it
> lately (I decided to test packinging the release candidate of llvm 21 and
> found a fun new bug that only shows up when binaries are stripped).
>
> I'm trying to remember where things were at, and what I'm coming up with
> was that I was going to revamp the struct with parameters to
> child_info_spawn::worker.  I think having int mode and then the const
> struct reference with all the other parameters makes sense.
>
>


-- 
Sebi
-- 
Sebastian Feld - IT security consultant