---

yaml
---
r: 155358
b: refs/heads/try2
c: 6672760
h: refs/heads/master
v: v3

Author: steveklabnik

[refs]

@@ -5,7 +5,7 @@ refs/heads/snap-stage3: 78a7676898d9f80ab540c6df5d4c9ce35bb50463
 refs/heads/try: 519addf6277dbafccbb4159db4b710c37eaa2ec5
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/ndm: f3868061cd7988080c30d6d5bf352a5a5fe2460b
-refs/heads/try2: fdd511d124523707b20227a7497aced1540add7e
+refs/heads/try2: 667276040feda6db6b4515ae7e82d7f4e1309f30
 refs/heads/dist-snap: ba4081a5a8573875fed17545846f6f6902c8ba8d
 refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596
 refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503

branches/try2/src/doc/reference.md

@@ -4041,47 +4041,20 @@ let y = x;
 An executing Rust program consists of a tree of tasks. A Rust _task_ consists
 of an entry function, a stack, a set of outgoing communication channels and
 incoming communication ports, and ownership of some portion of the heap of a
-single operating-system process. (We expect that many programs will not use
-channels and ports directly, but will instead use higher-level abstractions
-provided in standard libraries, such as pipes.)
-
-Multiple Rust tasks may coexist in a single operating-system process. The
-runtime scheduler maps tasks to a certain number of operating-system threads.
-By default, the scheduler chooses the number of threads based on the number of
-concurrent physical CPUs detected at startup. It's also possible to override
-this choice at runtime. When the number of tasks exceeds the number of threads
-— which is likely — the scheduler multiplexes the tasks onto
-threads.[^mnscheduler]
-
-[^mnscheduler]: This is an M:N scheduler, which is known to give suboptimal
-    results for CPU-bound concurrency problems. In such cases, running with the
-    same number of threads and tasks can yield better results. Rust has M:N
-    scheduling in order to support very large numbers of tasks in contexts where
-    threads are too resource-intensive to use in large number. The cost of
-    threads varies substantially per operating system, and is sometimes quite
-    low, so this flexibility is not always worth exploiting.
+single operating-system process.
 
 ### Communication between tasks
 
-Rust tasks are isolated and generally unable to interfere with one another's memory directly,
-except through [`unsafe` code](#unsafe-functions).
-All contact between tasks is mediated by safe forms of ownership transfer,
-and data races on memory are prohibited by the type system.
-
-Inter-task communication and co-ordination facilities are provided in the
-standard library. These include:
-
-- synchronous and asynchronous communication channels with various
-  communication topologies
-- read-only and read-write shared variables with various safe mutual exclusion
-  patterns
-- simple locks and semaphores
-
-When such facilities carry values, the values are restricted to the [`Send`
-type-kind](#type-kinds). Restricting communication interfaces to this kind
-ensures that no references or managed pointers move between tasks. Thus access
-to an entire data structure can be mediated through its owning "root" value; no
-further locking or copying is required to avoid data races within the
+Rust tasks are isolated and generally unable to interfere with one another's
+memory directly, except through [`unsafe` code](#unsafe-functions).  All
+contact between tasks is mediated by safe forms of ownership transfer, and data
+races on memory are prohibited by the type system.
+
+When you wish to send data between tasks, the values are restricted to the
+[`Send` type-kind](#type-kinds). Restricting communication interfaces to this
+kind ensures that no references or managed pointers move between tasks. Thus
+access to an entire data structure can be mediated through its owning "root"
+value; no further locking or copying is required to avoid data races within the
 substructure of such a value.
 
 ### Task lifecycle
@@ -4123,16 +4096,6 @@ A task in the *dead* state cannot transition to other states; it exists only to
 have its termination status inspected by other tasks, and/or to await
 reclamation when the last reference to it drops.
 
-### Task scheduling
-
-The currently scheduled task is given a finite *time slice* in which to
-execute, after which it is *descheduled* at a loop-edge or similar preemption
-point, and another task within is scheduled, pseudo-randomly.
-
-An executing task can yield control at any time, by making a library call to
-`std::task::yield`, which deschedules it immediately. Entering any other
-non-executing state (blocked, dead) similarly deschedules the task.
-
 # Runtime services, linkage and debugging
 
 The Rust _runtime_ is a relatively compact collection of C++ and Rust code that