Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove libgreen and runtime abstractions #17325

Closed
brson opened this issue Sep 16, 2014 · 4 comments · Fixed by #18967
Closed

Remove libgreen and runtime abstractions #17325

brson opened this issue Sep 16, 2014 · 4 comments · Fixed by #18967
Assignees
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. P-medium Medium priority

Comments

@brson
Copy link
Contributor

brson commented Sep 16, 2014

Tracking rust-lang/rfcs#230

@brson brson added A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows A-io B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. labels Sep 16, 2014
@aturon aturon self-assigned this Sep 16, 2014
@aturon
Copy link
Member

aturon commented Sep 18, 2014

Nominating for P-High, not on 1.0 milestone.

I'm going to miss the next triage meeting, but I'd like to confirm that the team does not view this as a 1.0 milestone issue, as it does not directly impact the std::io APIs.

I do plan to carry out this implementation work hand-in-hand with API stabilization for I/O, however.

@thestinger
Copy link
Contributor

It does impact the design in that many APIs were designed around the libuv-based runtime.

@aturon
Copy link
Member

aturon commented Sep 18, 2014

@thestinger

It does impact the design in that many APIs were designed around the libuv-based runtime.

To clarify:

  • The RFC is explicitly motivated by the desire to decouple std::io from the libuv runtime model.
  • However, the RFC itself (and therefore this issue) does not propose specific changes to the std::io API. It is about restructuring the implementation to enable such changes in the future.
  • I think we can and should consider specific changes to std::io as part of API stabilization (or via new RFCs, when the changes are substantial enough to warrant it.). But that effort is not part of this issue or the RFC it's tracking.
  • We are not generally blocking the 1.0 milestone on API stabilization effort, and do not plan to make specific promises about which APIs will be stable by the 1.0 release.
  • All that said, as I proposed in my original comment, I think it probably makes sense to work on API revisions hand-in-hand with the work on this issue.

@pnkfelix
Copy link
Member

Assigning P-high, not 1.0 milestone.

bors added a commit that referenced this issue Nov 9, 2014
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
aturon added a commit to aturon/rust that referenced this issue Nov 21, 2014
This commit removes most of the remaining runtime infrastructure related
to the green/native split. In particular, it removes the `Runtime` trait
and instead inlines the native implementation.

Closes rust-lang#17325

[breaking-change]
bors added a commit that referenced this issue Nov 21, 2014
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
mzabaluev added a commit to gi-rust/grust that referenced this issue Nov 23, 2014
There is no runtime system in the standard library now (see
[Rust issue #17325] (rust-lang/rust#17325)),
so the original separation of code specific to the native runtime
has lost its purpose.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. P-medium Medium priority
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants