]> git.lizzy.rs Git - rust.git/commit
auto merge of #8645 : alexcrichton/rust/issue-6436-run-non-blocking, r=brson
authorbors <bors@rust-lang.org>
Wed, 28 Aug 2013 04:55:42 +0000 (21:55 -0700)
committerbors <bors@rust-lang.org>
Wed, 28 Aug 2013 04:55:42 +0000 (21:55 -0700)
commitb8d1fa399402c71331aefd634d710004e00b73a6
tree575c040a4b277c8ff0107fdf673ef5a516eaf866
parentf22b4b169854c8a4ba86c16ee43327d6bcf94562
parent4635644746034bd01306159cc952cbdda23b3703
auto merge of #8645 : alexcrichton/rust/issue-6436-run-non-blocking, r=brson

This overhauls `std::run` to 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:
* This requires upgrading libuv. From the discussion on #6567, I took libuv master from a few days ago, applied one patch to fix process spawning with multiple event loops in libuv, and pushed to my own fork
* The build system for libuv has changed since we last used it. There's some extra checkout from a google build system which apparently does all the magic if you don't want to require autotools, and the google system just requires python. I updated the Makefile to get this build system and build libuv with it instead. This is untested on windows and arm, and both will probably need to see some improvement.
* This required adding some pipe bindings to libuv as well. Currently the support is pretty simple and probably completely unsafe for pipes, but you at least get read/write methods. This is necessary for capturing output of processes.
* I didn't redesign `std::run` at all, I simply tried to reimplement all the existing functionality on top of libuv. Some functions ended up dying, but nothing major. All uses of `std::run` in 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_send` because 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.
src/librustpkg/tests.rs