std.child_process: enable using non-standard pipes

[matu3ba]

The user provides an array of struct with info for direction for the pipe.
Each struct also contains the space for the input and output end of pipe,
which simplifies handling.
Typically a low number of non-standard pipes are used, so no premature optimization
and complicating the usage.
Also, it is expected that the upper bound of used pipes per process is comptime-known,
so slicing a continuous chunk would be most efficient.

• provide user with function pointer to enable parsing of necessary file descriptor
  on Linux and file handles on Windows in the child process
  • They can not be comptime-set, because the Kernel or user expects the program to
    work in all cases.
• keep logic the same as for posix_spawn
• use fcntl and SetHandleInformation to prevent file leakage into
  subsequently created children
• test if both fcntl and HandleInformation were correctly set
• test non-standard stream with 1 pipe type

Note: Standard streams are expected to be inheritable by child processes, so those
streams are "intentionally leaked to the child".

Benchmarking with realistic workloads is needed to decide the final design.
Especially, since storing space for one additionally unused pipe end can be wasteful.

[matu3ba]

Solution is to add those https://comp.os.ms-windows.programmer.win32.narkive.com/a4d3CdvQ/convert-handle-to-file-descriptor-works-in-vc-not-in-cygwin and while we are it these very nice functions to get the type of an underlying file descriptor:
https://jakash3.wordpress.com/2012/12/19/getting-file-descriptor-type-in-windows/

Andrew: "Libc is to be entirely avoided on Windows"

Thus: Use @intToPtr and @ptrToInt for Windows.

Reminder for me to implement eventually
https://www.youtube.com/watch?v=uhRWMGBjlO8&t=621s
haskell/directory#110

[matu3ba]

I would like to have some feedback from @marler8997 or another person that did more stuff with IPC on better benchmarks or to have some insight in use cases for the fast path aka posix_spawn.

So far I have this https://gist.github.com/matu3ba/c643b26b5e18a2aff20ef75468aa088d with a minimal printing hello world as child process and no user-defined function what to do in the parent right before spawn().

On Arch Linux I get round about these values, if repeated sufficiently often ./time parent:

real    0m0,263s
user    0m0,483s
sys     0m0,332s

With the changes applies (null inserted into spawn function):

real    0m0,255s
user    0m0,471s
sys     0m0,327s

[daurnimator]

I don't think this is a great type name

[matu3ba]

What about ExtraPipeProto? How would you call writing the pipe information to the child process?

[daurnimator]

Or just convention. e.g. SD_LISTEN_FDS_START is compile-time known to be 3

[matu3ba]

I may understand it wrong, what you are suggesting. As I understand it, you want to hardcode the file descriptor numbers.

Doing this for file descriptors other than 0,1,2 is error prone, even if we can assume that 3 is the next free one for the current process.
Take as example that the user has as additional requirement to open a file before using 3 or does other stuff, which uses file descriptors. Now 3 might be taken and the user introduced an error.

Another example, which is more of the worst case to debug: Another process uses file descriptor 3 already to do IPC with the one that now wants to spawn a child process and uses file descriptor 3 to do IPC.

[andrewrk]

I have attempted to rebase this against master branch on your behalf in order to re-run the failing CI checks. However there are conflicts. If you would like to continue working on this, please open a new PR against master branch.