19 Commits

Author SHA1 Message Date
Alex Crichton
58a51120a7 Update libuv
This update brings a few months of changes, but primarily a fix for the
following situation.

When creating a handle to stdin, libuv used to set the stdin handle to
nonblocking mode. This would end up affect this stdin handle across all
processes that shared it, which mean that stdin become nonblocking for everyone
using the same stdin. On linux, this also affected *stdout* because stdin/stdout
roughly point at the same thing.

This problem became apparent when running the test suite manually on a local
computer. The stdtest suite (running with libgreen) would set stdout to
nonblocking mode (as described above), and then the next test suite would always
fail for a printing failure (because stdout was returning EAGAIN).

This has been fixed upstream, joyent/libuv@342e8c, and this update pulls in this
fix. This also brings us in line with a recently upstreamed libuv patch.

Closes #13336
Closes #13355
2014-04-24 09:08:07 -07:00
Corey Richardson
0459ee77d0 Fix fallout from std::libc separation 2014-04-04 09:31:44 -07:00
Alex Crichton
bb9172d7b5 Fix fallout of removing default bounds
This is all purely fallout of getting the previous commit to compile.
2014-03-27 10:14:50 -07:00
Alex Crichton
7858065113 std: Rename Chan/Port types and constructor
* Chan<T> => Sender<T>
* Port<T> => Receiver<T>
* Chan::new() => channel()
* constructor returns (Sender, Receiver) instead of (Receiver, Sender)
* local variables named `port` renamed to `rx`
* local variables named `chan` renamed to `tx`

Closes #11765
2014-03-13 13:23:29 -07:00
Scott Lawrence
93e99b8be4 Remove do keyword from librustuv 2014-01-29 09:15:41 -05:00
Alex Crichton
0547fb9cad Fixup the rest of the tests in the compiler 2014-01-07 23:51:38 -08:00
Brian Anderson
3b1862a82f Don't allow newtype structs to be dereferenced. #6246 2014-01-04 14:44:12 -08:00
Alex Crichton
afd4e2ad8d rustuv: Get all tests passing again after refactor
All tests except for the homing tests are now working again with the
librustuv/libgreen refactoring. The homing-related tests are currently commented
out and now placed in the rustuv::homing module.

I plan on refactoring scheduler pool spawning in order to enable more homing
tests in a future commit.
2013-12-24 19:59:53 -08:00
Alex Crichton
429313de69 rustuv: Reimplement without using std::rt::sched
This reimplements librustuv without using the interfaces provided by the
scheduler in libstd. This solely uses the new Runtime trait in order to
interface with the local task and perform the necessary scheduling operations.

The largest snag in this refactoring is reimplementing homing. The new runtime
trait exposes no concept of "homing" a task or forcibly sending a task to a
remote scheduler (there is no concept of a scheduler). In order to reimplement
homing, the transferrence of tasks is now done at the librustuv level instead of
the scheduler level. This means that all I/O loops now have a concurrent queue
which receives homing messages and requests.

This allows the entire implementation of librustuv to be only dependent on the
runtime trait, severing all dependence of librustuv on the scheduler and related
green-thread functions.

This is all in preparation of the introduction of libgreen and libnative.

At the same time, I also took the liberty of removing all glob imports from
librustuv.
2013-12-24 14:42:00 -08:00
Patrick Walton
fd7a513bef libstd: Remove Cell from the library. 2013-12-10 17:55:09 -08:00
Patrick Walton
786dea207d libextra: Another round of de-Cell-ing.
34 uses of `Cell` remain.
2013-12-10 15:13:12 -08:00
Patrick Walton
a61a3678eb librustuv: Remove all non-proc uses of do from libextra and
`librustuv`.
2013-11-26 08:24:18 -08:00
Alex Crichton
df4c0b8e43 Make the uv bindings resilient to linked failure
In the ideal world, uv I/O could be canceled safely at any time. In reality,
however, we are unable to do this. Right now linked failure is fairly flaky as
implemented in the runtime, making it very difficult to test whether the linked
failure mechanisms inside of the uv bindings are ready for this kind of
interaction.

Right now, all constructors will execute in a task::unkillable block, and all
homing I/O operations will prevent linked failure in the duration of the homing
operation. What this means is that tasks which perform I/O are still susceptible
to linked failure, but the I/O operations themselves will never get interrupted.
Instead, the linked failure will be received at the edge of the I/O operation.
2013-11-10 01:37:11 -08:00
Alex Crichton
d08aadcc9a Update all uv tests to pass again 2013-11-10 01:37:11 -08:00
Alex Crichton
aa78c3d6f6 Clean up the remaining chunks of uv 2013-11-10 01:37:11 -08:00
Alex Crichton
6690bcb101 Fixing rebase conflicts and such
This cleans up the merging of removing ~fn() and removing C++ wrappers to a
compile-able and progress-ready state
2013-11-10 01:37:10 -08:00
Alex Crichton
28219fc679 Remove usage of ~fn() from uv async/idle 2013-11-10 01:37:10 -08:00
Alex Crichton
30c885ea52 uv: Remove lots of uv/C++ wrappers 2013-11-10 01:37:10 -08:00
Alex Crichton
201cab84e8 Move rust's uv implementation to its own crate
There are a few reasons that this is a desirable move to take:

1. Proof of concept that a third party event loop is possible
2. Clear separation of responsibility between rt::io and the uv-backend
3. Enforce in the future that the event loop is "pluggable" and replacable

Here's a quick summary of the points of this pull request which make this
possible:

* Two new lang items were introduced: event_loop, and event_loop_factory.
  The idea of a "factory" is to define a function which can be called with no
  arguments and will return the new event loop as a trait object. This factory
  is emitted to the crate map when building an executable. The factory doesn't
  have to exist, and when it doesn't then an empty slot is in the crate map and
  a basic event loop with no I/O support is provided to the runtime.

* When building an executable, then the rustuv crate will be linked by default
  (providing a default implementation of the event loop) via a similar method to
  injecting a dependency on libstd. This is currently the only location where
  the rustuv crate is ever linked.

* There is a new #[no_uv] attribute (implied by #[no_std]) which denies
  implicitly linking to rustuv by default

Closes #5019
2013-10-29 08:39:22 -07:00