From 8eba032f52a0b16b39a94267b4884f361e022c36 Mon Sep 17 00:00:00 2001 From: Paul Crowley Date: Sat, 10 Jan 2015 09:45:51 +0000 Subject: [PATCH] Purge references to Rust tasks from TRPL. --- src/doc/trpl/SUMMARY.md | 2 +- src/doc/trpl/error-handling.md | 4 ++-- src/doc/trpl/ffi.md | 13 ++++++------- src/doc/trpl/testing.md | 4 ++-- src/doc/trpl/{tasks.md => threads.md} | 0 src/doc/trpl/unsafe.md | 4 ++-- 6 files changed, 13 insertions(+), 14 deletions(-) rename src/doc/trpl/{tasks.md => threads.md} (100%) diff --git a/src/doc/trpl/SUMMARY.md b/src/doc/trpl/SUMMARY.md index 1a61c6d216b..aab03add905 100644 --- a/src/doc/trpl/SUMMARY.md +++ b/src/doc/trpl/SUMMARY.md @@ -26,7 +26,7 @@ * [Iterators](iterators.md) * [Generics](generics.md) * [Traits](traits.md) - * [Tasks](tasks.md) + * [Threads](threads.md) * [Error Handling](error-handling.md) * [III: Advanced Topics](advanced.md) * [FFI](ffi.md) diff --git a/src/doc/trpl/error-handling.md b/src/doc/trpl/error-handling.md index 3e7af5bbdde..4b1c92239ae 100644 --- a/src/doc/trpl/error-handling.md +++ b/src/doc/trpl/error-handling.md @@ -181,7 +181,7 @@ errors that can occur. # Non-recoverable errors with `panic!` In the case of an error that is unexpected and not recoverable, the `panic!` -macro will induce a panic. This will crash the current task, and give an error: +macro will induce a panic. This will crash the current thread, and give an error: ```{rust,ignore} panic!("boom"); @@ -190,7 +190,7 @@ panic!("boom"); gives ```text -task '
' panicked at 'boom', hello.rs:2 +thread '
' panicked at 'boom', hello.rs:2 ``` when you run it. diff --git a/src/doc/trpl/ffi.md b/src/doc/trpl/ffi.md index a65325af7be..e398ebe64db 100644 --- a/src/doc/trpl/ffi.md +++ b/src/doc/trpl/ffi.md @@ -166,12 +166,12 @@ GitHub](https://github.com/thestinger/rust-snappy). # Stack management -Rust tasks by default run on a *large stack*. This is actually implemented as a +Rust threads by default run on a *large stack*. This is actually implemented as a reserving a large segment of the address space and then lazily mapping in pages as they are needed. When calling an external C function, the code is invoked on the same stack as the rust stack. This means that there is no extra stack-switching mechanism in place because it is assumed that the large stack -for the rust task is plenty for the C function to have. +for the rust thread is plenty for the C function to have. A planned future improvement (not yet implemented at the time of this writing) is to have a guard page at the end of every rust stack. No rust function will @@ -184,8 +184,8 @@ For normal external function usage, this all means that there shouldn't be any need for any extra effort on a user's perspective. The C stack naturally interleaves with the rust stack, and it's "large enough" for both to interoperate. If, however, it is determined that a larger stack is necessary, -there are appropriate functions in the task spawning API to control the size of -the stack of the task which is spawned. +there are appropriate functions in the thread spawning API to control the size of +the stack of the thread which is spawned. # Destructors @@ -320,8 +320,7 @@ In the previously given examples the callbacks are invoked as a direct reaction to a function call to the external C library. The control over the current thread is switched from Rust to C to Rust for the execution of the callback, but in the end the callback is executed on the -same thread (and Rust task) that lead called the function which triggered -the callback. +same thread that called the function which triggered the callback. Things get more complicated when the external library spawns its own threads and invokes callbacks from there. @@ -329,7 +328,7 @@ In these cases access to Rust data structures inside the callbacks is especially unsafe and proper synchronization mechanisms must be used. Besides classical synchronization mechanisms like mutexes, one possibility in Rust is to use channels (in `std::comm`) to forward data from the C thread -that invoked the callback into a Rust task. +that invoked the callback into a Rust thread. If an asynchronous callback targets a special object in the Rust address space it is also absolutely necessary that no more callbacks are performed by the diff --git a/src/doc/trpl/testing.md b/src/doc/trpl/testing.md index 66da6395a5e..a304c60ba1a 100644 --- a/src/doc/trpl/testing.md +++ b/src/doc/trpl/testing.md @@ -96,7 +96,7 @@ test it_works ... FAILED failures: ---- it_works stdout ---- - task 'it_works' panicked at 'assertion failed: false', /home/steve/tmp/adder/src/lib.rs:3 + thread 'it_works' panicked at 'assertion failed: false', /home/steve/tmp/adder/src/lib.rs:3 @@ -105,7 +105,7 @@ failures: test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured -task '
' panicked at 'Some tests failed', /home/steve/src/rust/src/libtest/lib.rs:247 +thread '
' panicked at 'Some tests failed', /home/steve/src/rust/src/libtest/lib.rs:247 ``` Rust indicates that our test failed: diff --git a/src/doc/trpl/tasks.md b/src/doc/trpl/threads.md similarity index 100% rename from src/doc/trpl/tasks.md rename to src/doc/trpl/threads.md diff --git a/src/doc/trpl/unsafe.md b/src/doc/trpl/unsafe.md index 38427875a62..15f258cf8d4 100644 --- a/src/doc/trpl/unsafe.md +++ b/src/doc/trpl/unsafe.md @@ -182,7 +182,7 @@ code: - implement the `Drop` for resource clean-up via a destructor, and use RAII (Resource Acquisition Is Initialization). This reduces the need for any manual memory management by users, and automatically ensures - that clean-up is always run, even when the task panics. + that clean-up is always run, even when the thread panics. - ensure that any data stored behind a raw pointer is destroyed at the appropriate time. @@ -499,7 +499,7 @@ library, but without it you must define your own. The first of these three functions, `stack_exhausted`, is invoked whenever stack overflow is detected. This function has a number of restrictions about how it can be called and what it must do, but if the stack limit register is not being -maintained then a task always has an "infinite stack" and this function +maintained then a thread always has an "infinite stack" and this function shouldn't get triggered. The second of these three functions, `eh_personality`, is used by the