Re: posix_spawn support in core

[Daniel Colascione <dancol at dancol dot org>]

On 10/23/12 3:40 AM, Corinna Vinschen wrote:
> I 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.

> Last but not least, code contributions require a copyright assignment:
> http://cygwin.com/contrib.html

Of course.

Attachment: signature.asc
Description: OpenPGP digital signature