Post by Corinna VinschenI just realized that I missed to reply. Of course we would like to have
a posix_spawn. However, I'm not sure you can simply put a posix_spawn
over our exec/spawn implementation. This would require a redesign of
the exec/spawn code in the first place, isn't it?
Not really a redesign as much as an extension --- basically,
posix_spawn would propagate more information to its child than spawn
does today. With posix_spawn, the child would need to know to dup
certain file descriptors to other file descriptors, call setpgid, and
so on. Basically, we just send a list of instructions to the child and
have it execute them before it allowing initialization to proceed.
The one complication is that the specification requires that this
stream of instructions be executed *before* any O_CLOEXEC descriptors
are (notionally) closed in the child. Implementing this behavior
requires that the parent dup any O_CLOEXEC descriptors referenced by
the instruction list and pass these duped descriptors to the child
instead of the originals.
My POC library is a DLL that uses LD_PRELOAD to run code in the child
before the main child program runs. This code interprets the stream of
instructions supplied by the parent, which under the hood uses normal
spawn. This approach works, but it's a hack. Still, I can reuse most
of the code.
Implementing posix_spawn in the Cygwin core the right way would mean
extending child_info to include the additional information, then
implementing spawn in terms of posix_spawn. I don't think of this
approach as a major divergence from the existing design.
Post by Corinna Vinschenhttp://cygwin.com/contrib.html
Of course.