|
13 | 13 | *
|
14 | 14 | * An executing Rust program consists of a tree of tasks, each with their own
|
15 | 15 | * stack, and sole ownership of their allocated heap data. Tasks communicate
|
16 |
| - * with each other using ports and channels (see std::rt::comm for more info |
17 |
| - * about how communication works). |
| 16 | + * with each other using ports and channels. |
18 | 17 | *
|
19 |
| - * Tasks can be spawned in 3 different modes. |
| 18 | + * When a task fails, that failure will propagate to its parent (the task |
| 19 | + * that spawned it) and the parent will fail as well. The reverse is not |
| 20 | + * true: when a parent task fails its children will continue executing. When |
| 21 | + * the root (main) task fails, all tasks fail, and then so does the entire |
| 22 | + * process. |
20 | 23 | *
|
21 |
| - * * Bidirectionally linked: This is the default mode and it's what ```spawn``` does. |
22 |
| - * Failures will be propagated from parent to child and vice versa. |
23 |
| - * |
24 |
| - * * Unidirectionally linked (parent->child): This type of task can be created with |
25 |
| - * ```spawn_supervised```. In this case, failures are propagated from parent to child |
26 |
| - * but not the other way around. |
27 |
| - * |
28 |
| - * * Unlinked: Tasks can be completely unlinked. These tasks can be created by using |
29 |
| - * ```spawn_unlinked```. In this case failures are not propagated at all. |
30 |
| - * |
31 |
| - * Tasks' failure modes can be further configured. For instance, parent tasks can (un)watch |
32 |
| - * children failures. Please, refer to TaskBuilder's documentation bellow for more information. |
33 |
| - * |
34 |
| - * When a (bi|uni)directionally linked task fails, its failure will be propagated to all tasks |
35 |
| - * linked to it, this will cause such tasks to fail by a `linked failure`. |
36 |
| - * |
37 |
| - * Task Scheduling: |
38 |
| - * |
39 |
| - * By default, every task is created in the same scheduler as its parent, where it |
40 |
| - * is scheduled cooperatively with all other tasks in that scheduler. Some specialized |
41 |
| - * applications may want more control over their scheduling, in which case they can be |
42 |
| - * spawned into a new scheduler with the specific properties required. See TaskBuilder's |
43 |
| - * documentation bellow for more information. |
| 24 | + * Tasks may execute in parallel and are scheduled automatically by the |
| 25 | + * runtime. |
44 | 26 | *
|
45 | 27 | * # Example
|
46 | 28 | *
|
@@ -138,9 +120,17 @@ pub struct SchedOpts {
|
138 | 120 | * * name - A name for the task-to-be, for identification in failure messages.
|
139 | 121 | *
|
140 | 122 | * * sched - Specify the configuration of a new scheduler to create the task
|
141 |
| - * in. This is of particular importance for libraries which want to call |
142 |
| - * into foreign code that blocks. Without doing so in a different |
143 |
| - * scheduler other tasks will be impeded or even blocked indefinitely. |
| 123 | + * in |
| 124 | + * |
| 125 | + * By default, every task is created in the same scheduler as its |
| 126 | + * parent, where it is scheduled cooperatively with all other tasks |
| 127 | + * in that scheduler. Some specialized applications may want more |
| 128 | + * control over their scheduling, in which case they can be spawned |
| 129 | + * into a new scheduler with the specific properties required. |
| 130 | + * |
| 131 | + * This is of particular importance for libraries which want to call |
| 132 | + * into foreign code that blocks. Without doing so in a different |
| 133 | + * scheduler other tasks will be impeded or even blocked indefinitely. |
144 | 134 | */
|
145 | 135 | pub struct TaskOpts {
|
146 | 136 | linked: bool,
|
|
0 commit comments