Add bindings to libuv for process spawning #8645
Conversation
|
I believe that this is moving into its final form. I'm verifying now, but I believe that with RUST_THREADS=1 this passes I believe the problem is that when invoking So, for now, I think this is blocked on #8631. I'll need to make a lot of changes to rebase on top anyway. |
|
Now that #8631 has landed (awesome work!) I've rebased on top of that and implemented all pipe I/O, and process manipulation through that interface. I also refactored everything to mirror more closely what I realized the design was between rtio/uvio, and I think that it actually looks really nice now. The only unfortunate part is that the I'm still running r? @brson |
|
Great work! |
|
I do think it's a wart that UvProcessConfig (or whatever it's called) is exposed outside of |
|
Once this lands, I'll look implementing a At the same time, I think I may lift out |
|
Done on mac3, mac4, mac5, mac6. Should be good to try again. |
|
Currently this is blocked on being able to build on windows (the failure is legitimate) |
|
Can someone point me at the buildbot failure for this? I have a windows vm and I'll try to make time to work through the issue(s) and make a PR to @alexcrichton |
|
I was investigating this last night (sorry but working on windows is painfully slow for me), and the conclusion that I came to is that first we just need to figure out if libuv can build on mingw right now. It advertises itself as being able to do so, but I was unable to even just check out joyent/libuv and build it. If you could get that to work (and get a list of instructions), that's be a good first step! |
|
A couple of notes not directly related to this PR:
|
|
It'd be even more awesome if we could use libuv master directly because then we could only optionally build libuv (assuming a minimum version is available). Right now we'd have to wait for a fix of joyent/libuv#887 to get merged into master to be able to use tip. Beyond that though, there's not really anything extra that we have any more. It also turns out that their |
|
Ah, sorry I was under the impression that the bug-fixing commit was already merged into libuv master. |
|
Yeah sadly it's more of a workaround than an actual fix. It suffices for now, but I think that it would degrade performance as a whole for libuv (even single-threaded even loops) which is why they're hesitant to merge it and would prefer to flesh out a more proper fix first. |
|
Argh, I got so close! It turns out that this wedged the windows bots (hour of no output). I'll try to investigate tomorrow night. |
|
whoa, it appears you are correct. |
|
well, that makes me happy that it wasn't a runtime-type regression! |
This is a reopening of the libuv-upgrade part of rust-lang#8645. Hopefully this won't cause random segfaults all over the place. The windows regression in testing should also be fixed (it shouldn't build the whole compiler twice). A notable difference from before is that gyp is now a git submodule instead of always git-cloned at make time. This allows bundling for releases more easily. Closes rust-lang#8850
This is a reopening of the libuv-upgrade part of #8645. Hopefully this won't cause random segfaults all over the place. The windows regression in testing should also be fixed (it shouldn't build the whole compiler twice). A notable difference from before is that gyp is now a git submodule instead of always git-cloned at make time. This allows bundling for releases more easily. Closes #8850
This is a re-landing of rust-lang#8645, except that the bindings are *not* being used to power std::run just yet. Instead, this adds the bindings as standalone bindings inside the rt::io::process module. I made one major change from before, having to do with how pipes are created/bound. It's much clearer now when you can read/write to a pipe, as there's an explicit difference (different types) between an unbound and a bound pipe. The process configuration now takes unbound pipes (and consumes ownership of them), and will return corresponding pipe structures back if spawning is successful (otherwise everything is destroyed normally).
This is a re-landing of #8645, except that the bindings are *not* being used to power std::run just yet. Instead, this adds the bindings as standalone bindings inside the rt::io::process module. I made one major change from before, having to do with how pipes are created/bound. It's much clearer now when you can read/write to a pipe, as there's an explicit difference (different types) between an unbound and a bound pipe. The process configuration now takes unbound pipes (and consumes ownership of them), and will return corresponding pipe structures back if spawning is successful (otherwise everything is destroyed normally).
…archo Don't lint `manual_non_exhaustive` when the enum variant is used fixes rust-lang#5714 changelog: Don't lint `manual_non_exhaustive` when the enum variant is used
This overhauls
std::runto instead run on top of libuv. This is not in a mergeable state, I've been attempting to diagnose failures in the compiletest suite. I've managed to find a fair number of bugs so far, but I still don't seem to be done yet.Notable changes:
std::runat all, I simply tried to reimplement all the existing functionality on top of libuv. Some functions ended up dying, but nothing major. All uses ofstd::runin the compiler still work just fine.I'm not quite sure how the rest of the runtime deals with this, but I marked process structures as
no_sendbecause the waiting/waking up has to happen in the same event loop right now. If processes start migrating between event loops then very bad things can happen. This may be what threadsafe I/O would fix, and I would be more than willing to rebase on that if it lands first.Anyway, for now I wanted to put this up for review, I'm still investigating the corruption/deadlock bugs, but this is in an almost workable state. Once I find the bugs I'll also rebase on the current master.