Benoit Daloze

This is almost ready now. CI: https://github.com/eregon/childprocess/runs/2869763551?check_suite_focus=true Linux & macOS pass. Windows has only 2 failures: ``` Failures: 1) ChildProcess lets a detached child live on Failure/Error: expect(alive?(p_pid)).to_not be true...

> I don't have context on why the original `ChildProcess` backends were chosen over `Process.spawn`, but I assume there was _some_ reason. I don't know for sure, but I would...

I'll try to find some time to make a prototype but if anyone else is interested, go ahead and just mention it.

Here is a prototype, and it already passes all the specs, at least on Linux: https://github.com/enkessler/childprocess/compare/master...eregon:process-spawn I would think it works fine on Windows too, however the superclass is Unix::Process...

https://github.com/enkessler/childprocess/pull/175 already works well on UNIX, but not yet on Windows. I don't have a Windows dev machine, so that's rather impractical as I'd need to wait for CI to...

Update: it works on Windows now, there are only 2 failures left: https://github.com/enkessler/childprocess/pull/175#issuecomment-864585821 And the diff is `+166 −2,045`.

> Would it be possible to incrementally replace the internal implementation? Swap the OSX and Linux parts because core Ruby works fine but keep the Windows specific functionality in place...

I forgot, another advantage is `Process.spawn` is faster than fork+exec as currently used by `child_process`, because that can use vfork() or posix_spawn() for instance which needs to copy less from...

@dentarg Indeed, this is a clear real-world example of why sharing gem homes is problematic and AFAIK the only completely safe and solution is to just let gems be installed...

@postmodern It has been 3 years since https://github.com/postmodern/chruby/pull/419. In that time I had dozens of people mentioning this problem to me, and the only workaround for now is to use...