RFC: Remove runtime system, and move libgreen into an external library #230

Merged
merged 2 commits into from Sep 16, 2014

Conversation

Projects
None yet
10 participants
@aturon
Member

aturon commented Sep 9, 2014

This RFC proposes to remove the runtime system that is currently part of the
standard library, which currently allows the standard library to support both
native and green threading. In particular:

  • The libgreen crate and associated support will be moved out of tree, into a
    separate Cargo package.
  • The librustrt (the runtime) crate will be removed entirely.
  • The std::io implementation will be directly welded to native threads and
    system calls.
  • The std::io module will remain completely cross-platform, though separate
    platform-specific modules may be added at a later time.

Rendered

This is a follow-up to an earlier RFC.

@mcpherrinm

This comment has been minimized.

Show comment
Hide comment
@mcpherrinm

mcpherrinm Sep 10, 2014

From a library standpoint:
Many libraries do IO incidentally, often as logging. If these libraries use std::io, that could be prohibitive to using them in places like in nginx modules or other contexts where native IO is undesirable. I think we will need some sort of tooling or at least best practices if we can't just swap the runtime out from under libs. Of course we should probably handle logging seperately: the log crate could use some attention.

From an embedded systems standpoint:
I assume this means any new platform supported would need to add code to libnative: This is annoying if something like a microkernel or unikernel wanted to provide a runtime: That code is likely unsuitable for inclusion in libnative. Is there a good option here besides requiring a forked libnative?

From a library standpoint:
Many libraries do IO incidentally, often as logging. If these libraries use std::io, that could be prohibitive to using them in places like in nginx modules or other contexts where native IO is undesirable. I think we will need some sort of tooling or at least best practices if we can't just swap the runtime out from under libs. Of course we should probably handle logging seperately: the log crate could use some attention.

From an embedded systems standpoint:
I assume this means any new platform supported would need to add code to libnative: This is annoying if something like a microkernel or unikernel wanted to provide a runtime: That code is likely unsuitable for inclusion in libnative. Is there a good option here besides requiring a forked libnative?

@thestinger

This comment has been minimized.

Show comment
Hide comment
@thestinger

thestinger Sep 10, 2014

@mcpherrinm: You lose the ability to swap out the runtime dynamically but you could still provide a different implementation for a kernel and build high-level libraries against it. I think the vast majority of code that's interesting for a kernel will live at a lower level than a dependency on the full standard library though.

@mcpherrinm: You lose the ability to swap out the runtime dynamically but you could still provide a different implementation for a kernel and build high-level libraries against it. I think the vast majority of code that's interesting for a kernel will live at a lower level than a dependency on the full standard library though.

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Sep 10, 2014

Member

@mcpherrinm

Many libraries do IO incidentally, often as logging. If these libraries use std::io, that could be prohibitive to using them in places like in nginx modules or other contexts where native IO is undesirable. I think we will need some sort of tooling or at least best practices if we can't just swap the runtime out from under libs. Of course we should probably handle logging seperately: the log crate could use some attention.

I agree that this is a downside. But note that these pitfalls already exist with the current runtime system -- there are many innocent-looking ways to invoke blocking computation on a green thread that will block the underlying worker.

I assume this means any new platform supported would need to add code to libnative: This is annoying if something like a microkernel or unikernel wanted to provide a runtime: That code is likely unsuitable for inclusion in libnative. Is there a good option here besides requiring a forked libnative?

I also agree with the downside you point out for embedded systems. It's the usual tradeoff: having a layer of indirection as we do today is more flexible, but comes at a performance and binary size cost, and straps us to an abstraction of system capabilities that is often too limiting. I don't see any way out of this tradeoff, sadly.

Member

aturon commented Sep 10, 2014

@mcpherrinm

Many libraries do IO incidentally, often as logging. If these libraries use std::io, that could be prohibitive to using them in places like in nginx modules or other contexts where native IO is undesirable. I think we will need some sort of tooling or at least best practices if we can't just swap the runtime out from under libs. Of course we should probably handle logging seperately: the log crate could use some attention.

I agree that this is a downside. But note that these pitfalls already exist with the current runtime system -- there are many innocent-looking ways to invoke blocking computation on a green thread that will block the underlying worker.

I assume this means any new platform supported would need to add code to libnative: This is annoying if something like a microkernel or unikernel wanted to provide a runtime: That code is likely unsuitable for inclusion in libnative. Is there a good option here besides requiring a forked libnative?

I also agree with the downside you point out for embedded systems. It's the usual tradeoff: having a layer of indirection as we do today is more flexible, but comes at a performance and binary size cost, and straps us to an abstraction of system capabilities that is often too limiting. I don't see any way out of this tradeoff, sadly.

@arthurprs

This comment has been minimized.

Show comment
Hide comment
@arthurprs

arthurprs Sep 10, 2014

Great job on the writeup @aturon!

Great job on the writeup @aturon!

@Ericson2314

This comment has been minimized.

Show comment
Hide comment
@Ericson2314

Ericson2314 Sep 10, 2014

Contributor

Hmm? I'd think would be good for embedded / exokernel rust. Libnative will contain the bulk of the posix-, libc- or os- specific code backing the std, and little else. It would need to be replaced, but hopefully only it.

Contributor

Ericson2314 commented Sep 10, 2014

Hmm? I'd think would be good for embedded / exokernel rust. Libnative will contain the bulk of the posix-, libc- or os- specific code backing the std, and little else. It would need to be replaced, but hopefully only it.

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Sep 10, 2014

Member

@Ericson2314 I think what @mcpherrinm was getting at is that, in today's setup, the std code does not link directly against native; it goes through the Runtime trait. That means swapping in a different runtime implementation does not have to involve doing anything with native.

By contrast, this RFC proposes to make std depend on and bind directly to native, which means that you must modify native in these embedded situations.

I don't think that's a huge deal in terms of the actual programing involved (it should be roughly equivalent), but it means you can't just use an external crate.

Member

aturon commented Sep 10, 2014

@Ericson2314 I think what @mcpherrinm was getting at is that, in today's setup, the std code does not link directly against native; it goes through the Runtime trait. That means swapping in a different runtime implementation does not have to involve doing anything with native.

By contrast, this RFC proposes to make std depend on and bind directly to native, which means that you must modify native in these embedded situations.

I don't think that's a huge deal in terms of the actual programing involved (it should be roughly equivalent), but it means you can't just use an external crate.

@retep998

This comment has been minimized.

Show comment
Hide comment
@retep998

retep998 Sep 10, 2014

Member

While we're at it renaming liblibc to libsys can we rip out all the winapi stuff and create a proper libwinapi?

Member

retep998 commented Sep 10, 2014

While we're at it renaming liblibc to libsys can we rip out all the winapi stuff and create a proper libwinapi?

@tshepang

This comment has been minimized.

Show comment
Hide comment
@tshepang

tshepang Sep 10, 2014

Contributor

Why rename liblibc to the more ambiguous libsys?

Contributor

tshepang commented Sep 10, 2014

Why rename liblibc to the more ambiguous libsys?

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Sep 10, 2014

Member

@tshepang

Why rename liblibc to the more ambiguous libsys?

Oof, I should've spelled that out in the RFC. The crate includes a lot of (platform-specific) stuff beyond libc, and under the RFC the set of bindings would certainly grow. The idea was just to move all system bindings that are needed into one place.

There's some relationship to this earlier RFC that proposed to more aggressively centralize all platform-specific code, which is something we might want to consider as part of this refactoring.

Member

aturon commented Sep 10, 2014

@tshepang

Why rename liblibc to the more ambiguous libsys?

Oof, I should've spelled that out in the RFC. The crate includes a lot of (platform-specific) stuff beyond libc, and under the RFC the set of bindings would certainly grow. The idea was just to move all system bindings that are needed into one place.

There's some relationship to this earlier RFC that proposed to more aggressively centralize all platform-specific code, which is something we might want to consider as part of this refactoring.

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Sep 10, 2014

Member

@retep998 I could imagine breaking up the current libc crate into several platform-specific crates, and then having libsys just reexport. (A facade for C bindings...)

Member

aturon commented Sep 10, 2014

@retep998 I could imagine breaking up the current libc crate into several platform-specific crates, and then having libsys just reexport. (A facade for C bindings...)

@Ericson2314

This comment has been minimized.

Show comment
Hide comment
@Ericson2314

Ericson2314 Sep 10, 2014

Contributor

@aturon

By contrast, this RFC proposes to make std depend on and bind directly to native, which means that you must modify native in these embedded situations.

Ah I see. I was just thinking: it would be very nice if one could specify that their crate or cargo package provides the functionality of another crate or package. This would make linking the rest of std with a custom libnative, or linking an application with a unikernel that provides std or some part of it very slick.

cargo build servo --with=(rustic) # = firefoxOS++

I could imagine breaking up the current libc crate into several platform-specific crates, and then having libsys just reexport. (A facade for C bindings...)

Well, not to be a broken record, but I'd love any facade system that differentiated between C/POSIX standard C bindings, and kernel syscalls (even if for now the syscalls are just called via C).

Contributor

Ericson2314 commented Sep 10, 2014

@aturon

By contrast, this RFC proposes to make std depend on and bind directly to native, which means that you must modify native in these embedded situations.

Ah I see. I was just thinking: it would be very nice if one could specify that their crate or cargo package provides the functionality of another crate or package. This would make linking the rest of std with a custom libnative, or linking an application with a unikernel that provides std or some part of it very slick.

cargo build servo --with=(rustic) # = firefoxOS++

I could imagine breaking up the current libc crate into several platform-specific crates, and then having libsys just reexport. (A facade for C bindings...)

Well, not to be a broken record, but I'd love any facade system that differentiated between C/POSIX standard C bindings, and kernel syscalls (even if for now the syscalls are just called via C).

@retep998

This comment has been minimized.

Show comment
Hide comment
@retep998

retep998 Sep 10, 2014

Member

Because libstd depends on libnative, swapping out libnative with your own crate means building libstd against your own crate during the process of building rust. So really it is just a make issue.

Member

retep998 commented Sep 10, 2014

Because libstd depends on libnative, swapping out libnative with your own crate means building libstd against your own crate during the process of building rust. So really it is just a make issue.

@kballard

This comment has been minimized.

Show comment
Hide comment
@kballard

kballard Sep 11, 2014

Contributor

Things like logging do concern me a bit when trying to use alternative threading libraries instead of std::io. It seems to me that Rust could rename librustrt and keep it in the standard libraries instead of moving it to cargo, and then provide a TLS entry to document what runtime is being used on the current thread (where "no runtime" means libnative). This way crates like liblog that can reasonably expect to be used from arbitrary places and arbitrary threading models could explicitly use the renamed-rustrt I/O. If the TLS key does not indicate that there is a runtime in effect, this renamed-rustrt I/O API could fall back to libnative directly without using trait objects, thus keeping things pretty fast.

This approach has a few benefits:

  1. Since std::io wouldn't be based on this, it doesn't hold back any of the libnative I/O work. Presumably libnative will not be losing any existing functionality, so it shouldn't be hard to maintain the code that calls the libnative API if there's no active runtime.
  2. Clients of std::io don't have to care about the existence of this, and it shouldn't affect the setup work to embed Rust in another language (because if the TLS key has no value, which is the default, rustrt would fall back to calling either std::io or libnative APIs directly, without any allocation or trait objects).
  3. Keeping this in the standard library means other standard library crates like liblog can use it.

If it weren't for liblog, I'd say this should just be provided by cargo as the RFC suggests, but I can't think of any good way for liblog to integrate with the cargo package unless liblog itself actually defines the TLS key and the I/O API. Not only is that out of scope for liblog, but that's functionally identical to just keeping this minimal renamed rustrt crate.

I'm not sure right now what it should be renamed to, but I do think it should be renamed if it's no longer actually the "rust runtime".

Note that I'm not advocating for keeping libgreen as well. That can still be moved to cargo.

Contributor

kballard commented Sep 11, 2014

Things like logging do concern me a bit when trying to use alternative threading libraries instead of std::io. It seems to me that Rust could rename librustrt and keep it in the standard libraries instead of moving it to cargo, and then provide a TLS entry to document what runtime is being used on the current thread (where "no runtime" means libnative). This way crates like liblog that can reasonably expect to be used from arbitrary places and arbitrary threading models could explicitly use the renamed-rustrt I/O. If the TLS key does not indicate that there is a runtime in effect, this renamed-rustrt I/O API could fall back to libnative directly without using trait objects, thus keeping things pretty fast.

This approach has a few benefits:

  1. Since std::io wouldn't be based on this, it doesn't hold back any of the libnative I/O work. Presumably libnative will not be losing any existing functionality, so it shouldn't be hard to maintain the code that calls the libnative API if there's no active runtime.
  2. Clients of std::io don't have to care about the existence of this, and it shouldn't affect the setup work to embed Rust in another language (because if the TLS key has no value, which is the default, rustrt would fall back to calling either std::io or libnative APIs directly, without any allocation or trait objects).
  3. Keeping this in the standard library means other standard library crates like liblog can use it.

If it weren't for liblog, I'd say this should just be provided by cargo as the RFC suggests, but I can't think of any good way for liblog to integrate with the cargo package unless liblog itself actually defines the TLS key and the I/O API. Not only is that out of scope for liblog, but that's functionally identical to just keeping this minimal renamed rustrt crate.

I'm not sure right now what it should be renamed to, but I do think it should be renamed if it's no longer actually the "rust runtime".

Note that I'm not advocating for keeping libgreen as well. That can still be moved to cargo.

@thestinger

This comment has been minimized.

Show comment
Hide comment
@thestinger

thestinger Sep 11, 2014

It should be shown to be useful on a real world workload before the standard library expends any effort trying to support it. It doesn't make sense to add complexity and a maintenance burden without getting anything useful out of it. A good logging library needs to support flexible targets anyway.

It should be shown to be useful on a real world workload before the standard library expends any effort trying to support it. It doesn't make sense to add complexity and a maintenance burden without getting anything useful out of it. A good logging library needs to support flexible targets anyway.

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Sep 14, 2014

Member

@kballard I agree with @thestinger here: for now we should strive for maximal simplicity, and wait until it's clear what form of green threads, if any, is actually desired in the long run.

My sense at the moment is that we will definitely want to support truly lightweight threads (as laid out in this RFC), but it's much less clear that we'll want anything like Rust's current notion of green threads in the future.

This will mean that, if we want libgreen to continue to be usable, we will have to provide forks of various functionality there, including IO, logging, and others.

Member

aturon commented Sep 14, 2014

@kballard I agree with @thestinger here: for now we should strive for maximal simplicity, and wait until it's clear what form of green threads, if any, is actually desired in the long run.

My sense at the moment is that we will definitely want to support truly lightweight threads (as laid out in this RFC), but it's much less clear that we'll want anything like Rust's current notion of green threads in the future.

This will mean that, if we want libgreen to continue to be usable, we will have to provide forks of various functionality there, including IO, logging, and others.

@kballard

This comment has been minimized.

Show comment
Hide comment
@kballard

kballard Sep 15, 2014

Contributor

Ok, fair enough. I'm still hoping we can get basic support back in the standard libraries so code using liblog will behave acceptably in a green-threading situation (notably, because the standard libraries themselves use liblog), but I can accept that this is something that can be done later after experimenting with it as a cargo package.

Contributor

kballard commented Sep 15, 2014

Ok, fair enough. I'm still hoping we can get basic support back in the standard libraries so code using liblog will behave acceptably in a green-threading situation (notably, because the standard libraries themselves use liblog), but I can accept that this is something that can be done later after experimenting with it as a cargo package.

@mcpherrinm

This comment has been minimized.

Show comment
Hide comment
@mcpherrinm

mcpherrinm Sep 16, 2014

Logging in particular needs higher level configuration about where the I/O has to go to (whether network, shared memory, logfiles, the terminal, etc) if we want a robust and useful logging framework. Maybe we should just roll the lower level concerns (how to do that I/O) into some mechanism like that.

It's really just moving the dynamic dispatch for I/O into the liblog though, which feels kinda bad.

Logging in particular needs higher level configuration about where the I/O has to go to (whether network, shared memory, logfiles, the terminal, etc) if we want a robust and useful logging framework. Maybe we should just roll the lower level concerns (how to do that I/O) into some mechanism like that.

It's really just moving the dynamic dispatch for I/O into the liblog though, which feels kinda bad.

@sfackler

This comment has been minimized.

Show comment
Hide comment
@sfackler

sfackler Sep 16, 2014

Member

We already have the ability to change the logging implementation. Log calls route through a task local Logger trait object.

I think we can slightly expand that system (we'd want some ability to have subtasks inherit their parent tasks's logger in some way) and that should provide enough flexibility for third party logging frameworks to hook in. Trying to turn liblog into a fully featured logging framework like Log4J seems pretty out of scope for a standard library.

Member

sfackler commented Sep 16, 2014

We already have the ability to change the logging implementation. Log calls route through a task local Logger trait object.

I think we can slightly expand that system (we'd want some ability to have subtasks inherit their parent tasks's logger in some way) and that should provide enough flexibility for third party logging frameworks to hook in. Trying to turn liblog into a fully featured logging framework like Log4J seems pretty out of scope for a standard library.

@brson brson referenced this pull request in rust-lang/rust Sep 16, 2014

Closed

Remove libgreen and runtime abstractions #17325

@brson brson merged commit 5b2cd47 into rust-lang:master Sep 16, 2014

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Sep 16, 2014

Contributor

Merged as RFC 62. Discussion. Tracking.

Contributor

brson commented Sep 16, 2014

Merged as RFC 62. Discussion. Tracking.

aturon added a commit to aturon/rust that referenced this pull request Oct 1, 2014

Remove iotest macro
This commit removes the `iotest!` macro from `std::io`. The macro was
primarily used to ensure that all io-related tests were run on both
libnative and libgreen/librustuv. However, now that the librustuv stack
is being removed, the macro is no longer needed.

See the [runtime removal
RFC](rust-lang/rfcs#230) for more context.

[breaking-change]

aturon added a commit to aturon/rust that referenced this pull request Oct 1, 2014

Remove librustuv
This commit removes the `librustuv` crate.

See the [runtime removal
RFC](rust-lang/rfcs#230) for more context.

[breaking-change]

aturon added a commit to aturon/rust that referenced this pull request Oct 1, 2014

Remove libuv, gyp
This commit removes the libuv and gyp submodules, as well as all build
infrastructure related to them.

For more context, see the [runtime removal
RFC](rust-lang/rfcs#230)

[breaking-change]

@aturon aturon referenced this pull request in rust-lang/rust Oct 1, 2014

Merged

Remove librustuv and dependencies #17673

aturon added a commit to aturon/rust that referenced this pull request Oct 1, 2014

Remove iotest macro
This commit removes the `iotest!` macro from `std::io`. The macro was
primarily used to ensure that all io-related tests were run on both
libnative and libgreen/librustuv. However, now that the librustuv stack
is being removed, the macro is no longer needed.

See the [runtime removal
RFC](rust-lang/rfcs#230) for more context.

[breaking-change]

aturon added a commit to aturon/rust that referenced this pull request Oct 1, 2014

Remove librustuv
This commit removes the `librustuv` crate.

See the [runtime removal
RFC](rust-lang/rfcs#230) for more context.

See [green-rs](https://github.com/alexcrichton/green-rs/) for a possible
migration path if you wish to continue using green-threaded I/O. The
library provides its own I/O API surface.

[breaking-change]

aturon added a commit to aturon/rust that referenced this pull request Oct 1, 2014

Remove libuv, gyp
This commit removes the libuv and gyp submodules, as well as all build
infrastructure related to them.

For more context, see the [runtime removal
RFC](rust-lang/rfcs#230)

[breaking-change]

aturon added a commit to aturon/rust that referenced this pull request Oct 1, 2014

Remove std::io::signal
The `std::io::signal` API was only implemented under `librustuv`, which
is now being removed. Rather than keep around an unimplemented API, this
commit removes it altogether.

See the [runtime removal
RFC](rust-lang/rfcs#230) for more context.

See [green-rs](https://github.com/alexcrichton/green-rs/) for a possible
migration path for signal handling code, although in the long run we
plan to add native signal handling to `std::io`.

[breaking-change]

aturon added a commit to aturon/rust that referenced this pull request Oct 1, 2014

Remove librustuv
This commit removes the `librustuv` crate.

See the [runtime removal
RFC](rust-lang/rfcs#230) for more context.

See [green-rs](https://github.com/alexcrichton/green-rs/) for a possible
migration path if you wish to continue using green-threaded I/O. The
library provides its own I/O API surface.

[breaking-change]

aturon added a commit to aturon/rust that referenced this pull request Oct 1, 2014

Remove libuv, gyp
This commit removes the libuv and gyp submodules, as well as all build
infrastructure related to them.

For more context, see the [runtime removal
RFC](rust-lang/rfcs#230)

[breaking-change]

aturon added a commit to aturon/rust that referenced this pull request Oct 1, 2014

Remove librustuv
This commit removes the `librustuv` crate.

See the [runtime removal
RFC](rust-lang/rfcs#230) for more context.

See [green-rs](https://github.com/alexcrichton/green-rs/) for a possible
migration path if you wish to continue using green-threaded I/O. The
library provides its own I/O API surface.

[breaking-change]

aturon added a commit to aturon/rust that referenced this pull request Oct 1, 2014

Remove libuv, gyp
This commit removes the libuv and gyp submodules, as well as all build
infrastructure related to them.

For more context, see the [runtime removal
RFC](rust-lang/rfcs#230)

[breaking-change]

aturon added a commit to aturon/rust that referenced this pull request Oct 1, 2014

Remove std::io::signal
The `std::io::signal` API was only implemented under `librustuv`, which
is now being removed. Rather than keep around an unimplemented API, this
commit removes it altogether.

See the [runtime removal
RFC](rust-lang/rfcs#230) for more context.

See [green-rs](https://github.com/alexcrichton/green-rs/) for a possible
migration path for signal handling code, although in the long run we
plan to add native signal handling to `std::io`.

[breaking-change]

aturon added a commit to aturon/rust that referenced this pull request Oct 1, 2014

Remove iotest macro
This commit removes the `iotest!` macro from `std::io`. The macro was
primarily used to ensure that all io-related tests were run on both
libnative and libgreen/librustuv. However, now that the librustuv stack
is being removed, the macro is no longer needed.

See the [runtime removal
RFC](rust-lang/rfcs#230) for more context.

[breaking-change]

aturon added a commit to aturon/rust that referenced this pull request Oct 1, 2014

Remove librustuv
This commit removes the `librustuv` crate.

See the [runtime removal
RFC](rust-lang/rfcs#230) for more context.

See [green-rs](https://github.com/alexcrichton/green-rs/) for a possible
migration path if you wish to continue using green-threaded I/O. The
library provides its own I/O API surface.

[breaking-change]

aturon added a commit to aturon/rust that referenced this pull request Oct 1, 2014

Remove libuv, gyp
This commit removes the libuv and gyp submodules, as well as all build
infrastructure related to them.

For more context, see the [runtime removal
RFC](rust-lang/rfcs#230)

[breaking-change]

aturon added a commit to aturon/rust that referenced this pull request Oct 1, 2014

Remove std::io::signal
The `std::io::signal` API was only implemented under `librustuv`, which
is now being removed. Rather than keep around an unimplemented API, this
commit removes it altogether.

See the [runtime removal
RFC](rust-lang/rfcs#230) for more context.

See [green-rs](https://github.com/alexcrichton/green-rs/) for a possible
migration path for signal handling code, although in the long run we
plan to add native signal handling to `std::io`.

[breaking-change]

bors added a commit to rust-lang/rust that referenced this pull request Oct 1, 2014

auto merge of #17673 : aturon/rust/remove-uv, r=alexcrichton
This PR begins the process of [runtime removal](rust-lang/rfcs#230) by dismantling the `librustuv` crate and associated event loop.

The result is that, while `libgreen` can still be used for task scheduling purposes, it will no longer be feasible to use green-threaded I/O.

Removing the libuv-based event loop eases the transition away from the runtime system, which will be done incrementally.

In terms of visible API changes, this PR:

* Removes `std::io::signal`, which was never implemented on the native threading model.

* Removes the `iotest!` macro, which was previously used to run I/O tests on both green and native threading models.

* Removes the `green_start!` macro for starting an application with a `librustuv` event loop.

* Removes the `librustuv` crate itself.

It also removes the `libuv` and `gyp` submodules and adjusts the build system and copyright notices accordingly.

If you wish to continue using `librustuv` and green-threaded I/O, consider using [green-rs](https://github.com/alexcrichton/green-rs/), which provides its own I/O stack.

aturon added a commit to aturon/rust that referenced this pull request Oct 1, 2014

Remove libuv, gyp
This commit removes the libuv and gyp submodules, as well as all build
infrastructure related to them.

For more context, see the [runtime removal
RFC](rust-lang/rfcs#230)

[breaking-change]

aturon added a commit to aturon/rust that referenced this pull request Oct 1, 2014

Remove std::io::signal
The `std::io::signal` API was only implemented under `librustuv`, which
is now being removed. Rather than keep around an unimplemented API, this
commit removes it altogether.

See the [runtime removal
RFC](rust-lang/rfcs#230) for more context.

See [green-rs](https://github.com/alexcrichton/green-rs/) for a possible
migration path for signal handling code, although in the long run we
plan to add native signal handling to `std::io`.

[breaking-change]

bors added a commit to rust-lang/rust that referenced this pull request Oct 1, 2014

auto merge of #17673 : aturon/rust/remove-uv, r=alexcrichton
This PR begins the process of [runtime removal](rust-lang/rfcs#230) by dismantling the `librustuv` crate and associated event loop.

The result is that, while `libgreen` can still be used for task scheduling purposes, it will no longer be feasible to use green-threaded I/O.

Removing the libuv-based event loop eases the transition away from the runtime system, which will be done incrementally.

In terms of visible API changes, this PR:

* Removes `std::io::signal`, which was never implemented on the native threading model.

* Removes the `iotest!` macro, which was previously used to run I/O tests on both green and native threading models.

* Removes the `green_start!` macro for starting an application with a `librustuv` event loop.

* Removes the `librustuv` crate itself.

It also removes the `libuv` and `gyp` submodules and adjusts the build system and copyright notices accordingly.

If you wish to continue using `librustuv` and green-threaded I/O, consider using [green-rs](https://github.com/alexcrichton/green-rs/), which provides its own I/O stack.

@aturon aturon referenced this pull request in rust-lang/rust Nov 3, 2014

Merged

Remove rtio #18557

bors added a commit to rust-lang/rust that referenced this pull request Nov 6, 2014

auto merge of #18557 : aturon/rust/io-removal, r=alexcrichton
This PR includes a sequence of commits that gradually dismantles the `librustrt` `rtio` system -- the main trait previously used to abstract over green and native io. It also largely dismantles `libnative`, moving much of its code into `libstd` and refactoring as it does so.

TL;DR:

* Before this PR: `rustc hello.rs && wc -c hello` produces 715,996
* After this PR:  `rustc hello.rs && wc -c hello` produces 368,100

That is, this PR reduces the footprint of hello world by ~50%.

This is a major step toward #17325 (i.e. toward implementing the [runtime removal RFC](rust-lang/rfcs#230).) What remains is to pull out the scheduling, synchronization and task infrastructure, and to remove `libgreen`. These will be done soon in a follow-up PR.

Part of the work here is eliminating the `rtio` abstraction, which in many cases means bringing the implementation of io closer to the actual API presented in `std::io`.

Another aspect of this PR is the creation of two new, *private* modules within `std` that implement io:

* The `sys` module, which represents a platform-specific implementation of a number of low-level abstractions that are used directly within `std::io` and `std::os`. These "abstractions" are left largely the same as they were in `libnative` (except for the removal of `Arc` in file descriptors), but they are expected to evolve greatly over time. Organizationally, there are `sys/unix/` and `sys/windows/` directories which both implement the entire `sys` module hierarchy; this means that nearly all of the platform-specific code is isolated and you can get a handle on each platform in isolation.

* The `sys_common` module, which is rooted at `sys/common`, and provides a few pieces of private, low-level, but cross-platform functionality.

In the long term, the `sys` modules will provide hooks for exposing high-level platform-specific APIs as part of `libstd`. The first such API will be access to file descriptors from `std::io` abstractions, but a bit of design work remains before that step can be taken. 

The `sys_common` module includes some traits (like `AsFileDesc`) which allow communication of private details between modules in disparate locations in the hierarchy; this helps overcome the relatively simple hierarchical privacy system in Rust.

To emphasize: the organization in `sys` is *very preliminary* and the main goal was to migrate away from `rtio` as quickly and simply as possible. The design will certainly evolve over time, and all of the details are currently private.

Along the way, this PR also entirely removes signal handling, since it was only supported on `librustuv` which was removed a while ago. 

Because of the removal of APIs from `libnative` and `librustrt`, and the removal of signal handling, this is a:

[breaking-change]

Some of these APIs will return in public from from `std` over time.

r? @alexcrichton

bors added a commit to rust-lang/rust that referenced this pull request Nov 6, 2014

auto merge of #18557 : aturon/rust/io-removal, r=alexcrichton
This PR includes a sequence of commits that gradually dismantles the `librustrt` `rtio` system -- the main trait previously used to abstract over green and native io. It also largely dismantles `libnative`, moving much of its code into `libstd` and refactoring as it does so.

TL;DR:

* Before this PR: `rustc hello.rs && wc -c hello` produces 715,996
* After this PR:  `rustc hello.rs && wc -c hello` produces 368,100

That is, this PR reduces the footprint of hello world by ~50%.

This is a major step toward #17325 (i.e. toward implementing the [runtime removal RFC](rust-lang/rfcs#230).) What remains is to pull out the scheduling, synchronization and task infrastructure, and to remove `libgreen`. These will be done soon in a follow-up PR.

Part of the work here is eliminating the `rtio` abstraction, which in many cases means bringing the implementation of io closer to the actual API presented in `std::io`.

Another aspect of this PR is the creation of two new, *private* modules within `std` that implement io:

* The `sys` module, which represents a platform-specific implementation of a number of low-level abstractions that are used directly within `std::io` and `std::os`. These "abstractions" are left largely the same as they were in `libnative` (except for the removal of `Arc` in file descriptors), but they are expected to evolve greatly over time. Organizationally, there are `sys/unix/` and `sys/windows/` directories which both implement the entire `sys` module hierarchy; this means that nearly all of the platform-specific code is isolated and you can get a handle on each platform in isolation.

* The `sys_common` module, which is rooted at `sys/common`, and provides a few pieces of private, low-level, but cross-platform functionality.

In the long term, the `sys` modules will provide hooks for exposing high-level platform-specific APIs as part of `libstd`. The first such API will be access to file descriptors from `std::io` abstractions, but a bit of design work remains before that step can be taken. 

The `sys_common` module includes some traits (like `AsFileDesc`) which allow communication of private details between modules in disparate locations in the hierarchy; this helps overcome the relatively simple hierarchical privacy system in Rust.

To emphasize: the organization in `sys` is *very preliminary* and the main goal was to migrate away from `rtio` as quickly and simply as possible. The design will certainly evolve over time, and all of the details are currently private.

Along the way, this PR also entirely removes signal handling, since it was only supported on `librustuv` which was removed a while ago. 

Because of the removal of APIs from `libnative` and `librustrt`, and the removal of signal handling, this is a:

[breaking-change]

Some of these APIs will return in public from from `std` over time.

r? @alexcrichton

bors added a commit to rust-lang/rust that referenced this pull request Nov 7, 2014

auto merge of #18557 : aturon/rust/io-removal, r=alexcrichton
This PR includes a sequence of commits that gradually dismantles the `librustrt` `rtio` system -- the main trait previously used to abstract over green and native io. It also largely dismantles `libnative`, moving much of its code into `libstd` and refactoring as it does so.

TL;DR:

* Before this PR: `rustc hello.rs && wc -c hello` produces 715,996
* After this PR:  `rustc hello.rs && wc -c hello` produces 368,100

That is, this PR reduces the footprint of hello world by ~50%.

This is a major step toward #17325 (i.e. toward implementing the [runtime removal RFC](rust-lang/rfcs#230).) What remains is to pull out the scheduling, synchronization and task infrastructure, and to remove `libgreen`. These will be done soon in a follow-up PR.

Part of the work here is eliminating the `rtio` abstraction, which in many cases means bringing the implementation of io closer to the actual API presented in `std::io`.

Another aspect of this PR is the creation of two new, *private* modules within `std` that implement io:

* The `sys` module, which represents a platform-specific implementation of a number of low-level abstractions that are used directly within `std::io` and `std::os`. These "abstractions" are left largely the same as they were in `libnative` (except for the removal of `Arc` in file descriptors), but they are expected to evolve greatly over time. Organizationally, there are `sys/unix/` and `sys/windows/` directories which both implement the entire `sys` module hierarchy; this means that nearly all of the platform-specific code is isolated and you can get a handle on each platform in isolation.

* The `sys_common` module, which is rooted at `sys/common`, and provides a few pieces of private, low-level, but cross-platform functionality.

In the long term, the `sys` modules will provide hooks for exposing high-level platform-specific APIs as part of `libstd`. The first such API will be access to file descriptors from `std::io` abstractions, but a bit of design work remains before that step can be taken. 

The `sys_common` module includes some traits (like `AsFileDesc`) which allow communication of private details between modules in disparate locations in the hierarchy; this helps overcome the relatively simple hierarchical privacy system in Rust.

To emphasize: the organization in `sys` is *very preliminary* and the main goal was to migrate away from `rtio` as quickly and simply as possible. The design will certainly evolve over time, and all of the details are currently private.

Along the way, this PR also entirely removes signal handling, since it was only supported on `librustuv` which was removed a while ago. 

Because of the removal of APIs from `libnative` and `librustrt`, and the removal of signal handling, this is a:

[breaking-change]

Some of these APIs will return in public from from `std` over time.

r? @alexcrichton

bors added a commit to rust-lang/rust that referenced this pull request Nov 7, 2014

auto merge of #18557 : aturon/rust/io-removal, r=alexcrichton
This PR includes a sequence of commits that gradually dismantles the `librustrt` `rtio` system -- the main trait previously used to abstract over green and native io. It also largely dismantles `libnative`, moving much of its code into `libstd` and refactoring as it does so.

TL;DR:

* Before this PR: `rustc hello.rs && wc -c hello` produces 715,996
* After this PR:  `rustc hello.rs && wc -c hello` produces 368,100

That is, this PR reduces the footprint of hello world by ~50%.

This is a major step toward #17325 (i.e. toward implementing the [runtime removal RFC](rust-lang/rfcs#230).) What remains is to pull out the scheduling, synchronization and task infrastructure, and to remove `libgreen`. These will be done soon in a follow-up PR.

Part of the work here is eliminating the `rtio` abstraction, which in many cases means bringing the implementation of io closer to the actual API presented in `std::io`.

Another aspect of this PR is the creation of two new, *private* modules within `std` that implement io:

* The `sys` module, which represents a platform-specific implementation of a number of low-level abstractions that are used directly within `std::io` and `std::os`. These "abstractions" are left largely the same as they were in `libnative` (except for the removal of `Arc` in file descriptors), but they are expected to evolve greatly over time. Organizationally, there are `sys/unix/` and `sys/windows/` directories which both implement the entire `sys` module hierarchy; this means that nearly all of the platform-specific code is isolated and you can get a handle on each platform in isolation.

* The `sys_common` module, which is rooted at `sys/common`, and provides a few pieces of private, low-level, but cross-platform functionality.

In the long term, the `sys` modules will provide hooks for exposing high-level platform-specific APIs as part of `libstd`. The first such API will be access to file descriptors from `std::io` abstractions, but a bit of design work remains before that step can be taken. 

The `sys_common` module includes some traits (like `AsFileDesc`) which allow communication of private details between modules in disparate locations in the hierarchy; this helps overcome the relatively simple hierarchical privacy system in Rust.

To emphasize: the organization in `sys` is *very preliminary* and the main goal was to migrate away from `rtio` as quickly and simply as possible. The design will certainly evolve over time, and all of the details are currently private.

Along the way, this PR also entirely removes signal handling, since it was only supported on `librustuv` which was removed a while ago. 

Because of the removal of APIs from `libnative` and `librustrt`, and the removal of signal handling, this is a:

[breaking-change]

Some of these APIs will return in public from from `std` over time.

r? @alexcrichton

bors added a commit to rust-lang/rust that referenced this pull request Nov 8, 2014

auto merge of #18557 : aturon/rust/io-removal, r=alexcrichton
This PR includes a sequence of commits that gradually dismantles the `librustrt` `rtio` system -- the main trait previously used to abstract over green and native io. It also largely dismantles `libnative`, moving much of its code into `libstd` and refactoring as it does so.

TL;DR:

* Before this PR: `rustc hello.rs && wc -c hello` produces 715,996
* After this PR:  `rustc hello.rs && wc -c hello` produces 368,100

That is, this PR reduces the footprint of hello world by ~50%.

This is a major step toward #17325 (i.e. toward implementing the [runtime removal RFC](rust-lang/rfcs#230).) What remains is to pull out the scheduling, synchronization and task infrastructure, and to remove `libgreen`. These will be done soon in a follow-up PR.

Part of the work here is eliminating the `rtio` abstraction, which in many cases means bringing the implementation of io closer to the actual API presented in `std::io`.

Another aspect of this PR is the creation of two new, *private* modules within `std` that implement io:

* The `sys` module, which represents a platform-specific implementation of a number of low-level abstractions that are used directly within `std::io` and `std::os`. These "abstractions" are left largely the same as they were in `libnative` (except for the removal of `Arc` in file descriptors), but they are expected to evolve greatly over time. Organizationally, there are `sys/unix/` and `sys/windows/` directories which both implement the entire `sys` module hierarchy; this means that nearly all of the platform-specific code is isolated and you can get a handle on each platform in isolation.

* The `sys_common` module, which is rooted at `sys/common`, and provides a few pieces of private, low-level, but cross-platform functionality.

In the long term, the `sys` modules will provide hooks for exposing high-level platform-specific APIs as part of `libstd`. The first such API will be access to file descriptors from `std::io` abstractions, but a bit of design work remains before that step can be taken. 

The `sys_common` module includes some traits (like `AsFileDesc`) which allow communication of private details between modules in disparate locations in the hierarchy; this helps overcome the relatively simple hierarchical privacy system in Rust.

To emphasize: the organization in `sys` is *very preliminary* and the main goal was to migrate away from `rtio` as quickly and simply as possible. The design will certainly evolve over time, and all of the details are currently private.

Along the way, this PR also entirely removes signal handling, since it was only supported on `librustuv` which was removed a while ago. 

Because of the removal of APIs from `libnative` and `librustrt`, and the removal of signal handling, this is a:

[breaking-change]

Some of these APIs will return in public from from `std` over time.

r? @alexcrichton

bors added a commit to rust-lang/rust that referenced this pull request Nov 9, 2014

auto merge of #18557 : aturon/rust/io-removal, r=alexcrichton
This PR includes a sequence of commits that gradually dismantles the `librustrt` `rtio` system -- the main trait previously used to abstract over green and native io. It also largely dismantles `libnative`, moving much of its code into `libstd` and refactoring as it does so.

TL;DR:

* Before this PR: `rustc hello.rs && wc -c hello` produces 715,996
* After this PR:  `rustc hello.rs && wc -c hello` produces 368,100

That is, this PR reduces the footprint of hello world by ~50%.

This is a major step toward #17325 (i.e. toward implementing the [runtime removal RFC](rust-lang/rfcs#230).) What remains is to pull out the scheduling, synchronization and task infrastructure, and to remove `libgreen`. These will be done soon in a follow-up PR.

Part of the work here is eliminating the `rtio` abstraction, which in many cases means bringing the implementation of io closer to the actual API presented in `std::io`.

Another aspect of this PR is the creation of two new, *private* modules within `std` that implement io:

* The `sys` module, which represents a platform-specific implementation of a number of low-level abstractions that are used directly within `std::io` and `std::os`. These "abstractions" are left largely the same as they were in `libnative` (except for the removal of `Arc` in file descriptors), but they are expected to evolve greatly over time. Organizationally, there are `sys/unix/` and `sys/windows/` directories which both implement the entire `sys` module hierarchy; this means that nearly all of the platform-specific code is isolated and you can get a handle on each platform in isolation.

* The `sys_common` module, which is rooted at `sys/common`, and provides a few pieces of private, low-level, but cross-platform functionality.

In the long term, the `sys` modules will provide hooks for exposing high-level platform-specific APIs as part of `libstd`. The first such API will be access to file descriptors from `std::io` abstractions, but a bit of design work remains before that step can be taken. 

The `sys_common` module includes some traits (like `AsFileDesc`) which allow communication of private details between modules in disparate locations in the hierarchy; this helps overcome the relatively simple hierarchical privacy system in Rust.

To emphasize: the organization in `sys` is *very preliminary* and the main goal was to migrate away from `rtio` as quickly and simply as possible. The design will certainly evolve over time, and all of the details are currently private.

Along the way, this PR also entirely removes signal handling, since it was only supported on `librustuv` which was removed a while ago. 

Because of the removal of APIs from `libnative` and `librustrt`, and the removal of signal handling, this is a:

[breaking-change]

Some of these APIs will return in public from from `std` over time.

r? @alexcrichton

bors added a commit to rust-lang/rust that referenced this pull request Nov 9, 2014

auto merge of #18557 : aturon/rust/io-removal, r=alexcrichton
This PR includes a sequence of commits that gradually dismantles the `librustrt` `rtio` system -- the main trait previously used to abstract over green and native io. It also largely dismantles `libnative`, moving much of its code into `libstd` and refactoring as it does so.

TL;DR:

* Before this PR: `rustc hello.rs && wc -c hello` produces 715,996
* After this PR:  `rustc hello.rs && wc -c hello` produces 368,100

That is, this PR reduces the footprint of hello world by ~50%.

This is a major step toward #17325 (i.e. toward implementing the [runtime removal RFC](rust-lang/rfcs#230).) What remains is to pull out the scheduling, synchronization and task infrastructure, and to remove `libgreen`. These will be done soon in a follow-up PR.

Part of the work here is eliminating the `rtio` abstraction, which in many cases means bringing the implementation of io closer to the actual API presented in `std::io`.

Another aspect of this PR is the creation of two new, *private* modules within `std` that implement io:

* The `sys` module, which represents a platform-specific implementation of a number of low-level abstractions that are used directly within `std::io` and `std::os`. These "abstractions" are left largely the same as they were in `libnative` (except for the removal of `Arc` in file descriptors), but they are expected to evolve greatly over time. Organizationally, there are `sys/unix/` and `sys/windows/` directories which both implement the entire `sys` module hierarchy; this means that nearly all of the platform-specific code is isolated and you can get a handle on each platform in isolation.

* The `sys_common` module, which is rooted at `sys/common`, and provides a few pieces of private, low-level, but cross-platform functionality.

In the long term, the `sys` modules will provide hooks for exposing high-level platform-specific APIs as part of `libstd`. The first such API will be access to file descriptors from `std::io` abstractions, but a bit of design work remains before that step can be taken. 

The `sys_common` module includes some traits (like `AsFileDesc`) which allow communication of private details between modules in disparate locations in the hierarchy; this helps overcome the relatively simple hierarchical privacy system in Rust.

To emphasize: the organization in `sys` is *very preliminary* and the main goal was to migrate away from `rtio` as quickly and simply as possible. The design will certainly evolve over time, and all of the details are currently private.

Along the way, this PR also entirely removes signal handling, since it was only supported on `librustuv` which was removed a while ago. 

Because of the removal of APIs from `libnative` and `librustrt`, and the removal of signal handling, this is a:

[breaking-change]

Some of these APIs will return in public from from `std` over time.

r? @alexcrichton

@elijahandrews elijahandrews referenced this pull request in joyent/libuv Nov 10, 2014

Closed

Remove Rust from users #1572

bors added a commit to rust-lang/rust that referenced this pull request Nov 17, 2014

auto merge of #18967 : aturon/rust/remove-runtime, r=alexcrichton
This PR completes the removal of the runtime system and green-threaded abstractions as part of implementing [RFC 230](rust-lang/rfcs#230).

Specifically:

* It removes the `Runtime` trait and `bookkeeping` module, welding the scheduling infrastructure directly to native threads, and allowing a Rust program to shut down immediately once its main thread has terminated even if others are still running.

* It removes `libgreen` and `libnative` entirely.

* It rewrites `sync::mutex` as a trivial layer on top of native mutexes. Eventually, the two modules will be merged.

* It hides the vast majority of `std::rt`.

This completes the basic task of removing the runtime system (I/O and scheduling) and components that depend on it. 

After this lands, a follow-up PR will pull the `rustrt` crate back into `std`, turn `std::task` into `std::thread` (with API changes to go along with it). Other changes, including new [TLS](rust-lang/rfcs#461) and synchronization are in the RFC or pre-RFC phase.

Closes #17325
Closes #18687

[breaking-change]

r? @alexcrichton

bors added a commit to rust-lang/rust that referenced this pull request Nov 18, 2014

auto merge of #18967 : aturon/rust/remove-runtime, r=alexcrichton
This PR completes the removal of the runtime system and green-threaded abstractions as part of implementing [RFC 230](rust-lang/rfcs#230).

Specifically:

* It removes the `Runtime` trait and `bookkeeping` module, welding the scheduling infrastructure directly to native threads, and allowing a Rust program to shut down immediately once its main thread has terminated even if others are still running.

* It removes `libgreen` and `libnative` entirely.

* It rewrites `sync::mutex` as a trivial layer on top of native mutexes. Eventually, the two modules will be merged.

* It hides the vast majority of `std::rt`.

This completes the basic task of removing the runtime system (I/O and scheduling) and components that depend on it. 

After this lands, a follow-up PR will pull the `rustrt` crate back into `std`, turn `std::task` into `std::thread` (with API changes to go along with it). Other changes, including new [TLS](rust-lang/rfcs#461) and synchronization are in the RFC or pre-RFC phase.

Closes #17325
Closes #18687

[breaking-change]

r? @alexcrichton

bors added a commit to rust-lang/rust that referenced this pull request Nov 18, 2014

auto merge of #18967 : aturon/rust/remove-runtime, r=alexcrichton,ale…
…xcrichton

This PR completes the removal of the runtime system and green-threaded abstractions as part of implementing [RFC 230](rust-lang/rfcs#230).

Specifically:

* It removes the `Runtime` trait and `bookkeeping` module, welding the scheduling infrastructure directly to native threads, and allowing a Rust program to shut down immediately once its main thread has terminated even if others are still running.

* It removes `libgreen` and `libnative` entirely.

* It rewrites `sync::mutex` as a trivial layer on top of native mutexes. Eventually, the two modules will be merged.

* It hides the vast majority of `std::rt`.

This completes the basic task of removing the runtime system (I/O and scheduling) and components that depend on it. 

After this lands, a follow-up PR will pull the `rustrt` crate back into `std`, turn `std::task` into `std::thread` (with API changes to go along with it). Other changes, including new [TLS](rust-lang/rfcs#461) and synchronization are in the RFC or pre-RFC phase.

Closes #17325
Closes #18687

[breaking-change]

r? @alexcrichton

bors added a commit to rust-lang/rust that referenced this pull request Nov 19, 2014

auto merge of #18967 : aturon/rust/remove-runtime, r=alexcrichton
This PR completes the removal of the runtime system and green-threaded abstractions as part of implementing [RFC 230](rust-lang/rfcs#230).

Specifically:

* It removes the `Runtime` trait and `bookkeeping` module, welding the scheduling infrastructure directly to native threads, and allowing a Rust program to shut down immediately once its main thread has terminated even if others are still running.

* It removes `libgreen` and `libnative` entirely.

* It rewrites `sync::mutex` as a trivial layer on top of native mutexes. Eventually, the two modules will be merged.

* It hides the vast majority of `std::rt`.

This completes the basic task of removing the runtime system (I/O and scheduling) and components that depend on it. 

After this lands, a follow-up PR will pull the `rustrt` crate back into `std`, turn `std::task` into `std::thread` (with API changes to go along with it). Other changes, including new [TLS](rust-lang/rfcs#461) and synchronization are in the RFC or pre-RFC phase.

Closes #17325
Closes #18687

[breaking-change]

r? @alexcrichton

bors added a commit to rust-lang/rust that referenced this pull request Nov 19, 2014

auto merge of #18967 : aturon/rust/remove-runtime, r=alexcrichton
This PR completes the removal of the runtime system and green-threaded abstractions as part of implementing [RFC 230](rust-lang/rfcs#230).

Specifically:

* It removes the `Runtime` trait and `bookkeeping` module, welding the scheduling infrastructure directly to native threads, and allowing a Rust program to shut down immediately once its main thread has terminated even if others are still running.

* It removes `libgreen` and `libnative` entirely.

* It rewrites `sync::mutex` as a trivial layer on top of native mutexes. Eventually, the two modules will be merged.

* It hides the vast majority of `std::rt`.

This completes the basic task of removing the runtime system (I/O and scheduling) and components that depend on it. 

After this lands, a follow-up PR will pull the `rustrt` crate back into `std`, turn `std::task` into `std::thread` (with API changes to go along with it). Other changes, including new [TLS](rust-lang/rfcs#461) and synchronization are in the RFC or pre-RFC phase.

Closes #17325
Closes #18687

[breaking-change]

r? @alexcrichton

bors added a commit to rust-lang/rust that referenced this pull request Nov 20, 2014

auto merge of #18967 : aturon/rust/remove-runtime, r=alexcrichton
This PR completes the removal of the runtime system and green-threaded abstractions as part of implementing [RFC 230](rust-lang/rfcs#230).

Specifically:

* It removes the `Runtime` trait and `bookkeeping` module, welding the scheduling infrastructure directly to native threads, and allowing a Rust program to shut down immediately once its main thread has terminated even if others are still running.

* It removes `libgreen` and `libnative` entirely.

* It rewrites `sync::mutex` as a trivial layer on top of native mutexes. Eventually, the two modules will be merged.

* It hides the vast majority of `std::rt`.

This completes the basic task of removing the runtime system (I/O and scheduling) and components that depend on it. 

After this lands, a follow-up PR will pull the `rustrt` crate back into `std`, turn `std::task` into `std::thread` (with API changes to go along with it). Other changes, including new [TLS](rust-lang/rfcs#461) and synchronization are in the RFC or pre-RFC phase.

Closes #17325
Closes #18687

[breaking-change]

r? @alexcrichton

bors added a commit to rust-lang/rust that referenced this pull request Nov 20, 2014

auto merge of #18967 : aturon/rust/remove-runtime, r=alexcrichton
This PR completes the removal of the runtime system and green-threaded abstractions as part of implementing [RFC 230](rust-lang/rfcs#230).

Specifically:

* It removes the `Runtime` trait and `bookkeeping` module, welding the scheduling infrastructure directly to native threads, and allowing a Rust program to shut down immediately once its main thread has terminated even if others are still running.

* It removes `libgreen` and `libnative` entirely.

* It rewrites `sync::mutex` as a trivial layer on top of native mutexes. Eventually, the two modules will be merged.

* It hides the vast majority of `std::rt`.

This completes the basic task of removing the runtime system (I/O and scheduling) and components that depend on it. 

After this lands, a follow-up PR will pull the `rustrt` crate back into `std`, turn `std::task` into `std::thread` (with API changes to go along with it). Other changes, including new [TLS](rust-lang/rfcs#461) and synchronization are in the RFC or pre-RFC phase.

Closes #17325
Closes #18687

[breaking-change]

r? @alexcrichton

bors added a commit to rust-lang/rust that referenced this pull request Nov 21, 2014

auto merge of #18967 : aturon/rust/remove-runtime, r=alexcrichton
This PR completes the removal of the runtime system and green-threaded abstractions as part of implementing [RFC 230](rust-lang/rfcs#230).

Specifically:

* It removes the `Runtime` trait, welding the scheduling infrastructure directly to native threads.

* It removes `libgreen` and `libnative` entirely.

* It rewrites `sync::mutex` as a trivial layer on top of native mutexes. Eventually, the two modules will be merged.

* It hides the vast majority of `std::rt`.

This completes the basic task of removing the runtime system (I/O and scheduling) and components that depend on it. 

After this lands, a follow-up PR will pull the `rustrt` crate back into `std`, turn `std::task` into `std::thread` (with API changes to go along with it), and completely cut out the remaining startup/teardown sequence. Other changes, including new [TLS](rust-lang/rfcs#461) and synchronization are in the RFC or pre-RFC phase.

Closes #17325
Closes #18687

[breaking-change]

r? @alexcrichton

simnalamburt added a commit to simnalamburt/opengl-practice that referenced this pull request Dec 3, 2014

Catch up rust update
1.  `libnative` has been removed from the rust standard library.
    Please consult rust-lang/rfcs#230
2.  Updated project dependencies.

simnalamburt added a commit to simnalamburt/opengl-practice that referenced this pull request Dec 3, 2014

Catch up rust update
1.  `libnative` has been removed from the rust standard library
    Please consult rust-lang/rfcs#230
2.  Updated project dependencies
3.  Apply `glfw-rs` API update

@chriskrycho chriskrycho referenced this pull request in rust-lang/rust Dec 30, 2016

Closed

Document all features in the reference #38643

0 of 17 tasks complete

withoutboats pushed a commit to withoutboats/rfcs that referenced this pull request Jan 15, 2017

Rename finished => ok, failed => err
Also rename done => result, and add a bunch of reexports for all the old names.
For now the `Result` type is exported as `FutureResult` to prevent conflict with
the `Result` type (very likely to happen), but we should change that as part of
0.2.

Closes #230

@chriskrycho chriskrycho referenced this pull request in rust-lang-nursery/reference Mar 11, 2017

Closed

Document all features #9

18 of 48 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment