diff options
| author | bors <bors@rust-lang.org> | 2014-12-19 08:28:52 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2014-12-19 08:28:52 +0000 |
| commit | 0efafac398ff7f28c5f0fe756c15b9008b3e0534 (patch) | |
| tree | 2e8279b94829b65868049d2e3df0b9a6c3365a8f /src/rustllvm/RustWrapper.cpp | |
| parent | 6bdce25e155d846bb9252fa4a18baef7e74cf8bf (diff) | |
| parent | 903c5a8f69714382ec9fc22745f902c3e219cb68 (diff) | |
| download | rust-0efafac398ff7f28c5f0fe756c15b9008b3e0534.tar.gz rust-0efafac398ff7f28c5f0fe756c15b9008b3e0534.zip | |
auto merge of #19654 : aturon/rust/merge-rt, r=alexcrichton
This PR substantially narrows the notion of a "runtime" in Rust, and allows calling into Rust code directly without any setup or teardown. After this PR, the basic "runtime support" in Rust will consist of: * Unwinding and backtrace support * Stack guards Other support, such as helper threads for timers or the notion of a "current thread" are initialized automatically upon first use. When using Rust in an embedded context, it should now be possible to call a Rust function directly as a C function with absolutely no setup, though in that case panics will cause the process to abort. In this regard, the C/Rust interface will look much like the C/C++ interface. In more detail, this PR: * Merges `librustrt` back into `std::rt`, undoing the facade. While doing so, it removes a substantial amount of redundant functionality (such as mutexes defined in the `rt` module). Code using `librustrt` can now call into `std::rt` to e.g. start executing Rust code with unwinding support. * Allows all runtime data to be initialized lazily, including the "current thread", the "at_exit" infrastructure, and the "args" storage. * Deprecates and largely removes `std::task` along with the widespread requirement that there be a "current task" for many APIs in `std`. The entire task infrastructure is replaced with `std::thread`, which provides a more standard API for manipulating and creating native OS threads. In particular, it's possible to join on a created thread, and to get a handle to the currently-running thread. In addition, threads are equipped with some basic blocking support in the form of `park`/`unpark` operations (following a tradition in some OSes as well as the JVM). See the `std::thread` documentation for more details. * Channels are refactored to use a new internal blocking infrastructure that itself sits on top of `park`/`unpark`. One important change here is that a Rust program ends when its main thread does, following most threading models. On the other hand, threads will often be created with an RAII-style join handle that will re-institute blocking semantics naturally (and with finer control). This is very much a: [breaking-change] Closes #18000 r? @alexcrichton
Diffstat (limited to 'src/rustllvm/RustWrapper.cpp')
0 files changed, 0 insertions, 0 deletions
