Skip to content

Commit fd0de8b

Browse files
committed
doc: Split out task tutorail. Add links to sub-tutorials
1 parent 6caafaa commit fd0de8b

File tree

5 files changed

+237
-251
lines changed

5 files changed

+237
-251
lines changed

configure

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -508,6 +508,7 @@ do
508508
make_dir $h/test/doc-tutorial-ffi
509509
make_dir $h/test/doc-tutorial-macros
510510
make_dir $h/test/doc-tutorial-borrowed-ptr
511+
make_dir $h/test/doc-tutorial-tasks
511512
make_dir $h/test/doc-ref
512513
done
513514

doc/tutorial-tasks.md

Lines changed: 173 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,173 @@
1+
% Tasks and communication in Rust
2+
3+
Rust supports a system of lightweight tasks, similar to what is found
4+
in Erlang or other actor systems. Rust tasks communicate via messages
5+
and do not share data. However, it is possible to send data without
6+
copying it by making use of [the exchange heap](#unique-boxes), which
7+
allow the sending task to release ownership of a value, so that the
8+
receiving task can keep on using it.
9+
10+
> ***Note:*** As Rust evolves, we expect the task API to grow and
11+
> change somewhat. The tutorial documents the API as it exists today.
12+
13+
# Spawning a task
14+
15+
Spawning a task is done using the various spawn functions in the
16+
module `task`. Let's begin with the simplest one, `task::spawn()`:
17+
18+
~~~~
19+
use task::spawn;
20+
use io::println;
21+
22+
let some_value = 22;
23+
24+
do spawn {
25+
println(~"This executes in the child task.");
26+
println(fmt!("%d", some_value));
27+
}
28+
~~~~
29+
30+
The argument to `task::spawn()` is a [unique
31+
closure](#unique-closures) of type `fn~()`, meaning that it takes no
32+
arguments and generates no return value. The effect of `task::spawn()`
33+
is to fire up a child task that will execute the closure in parallel
34+
with the creator.
35+
36+
# Communication
37+
38+
Now that we have spawned a child task, it would be nice if we could
39+
communicate with it. This is done using *pipes*. Pipes are simply a
40+
pair of endpoints, with one for sending messages and another for
41+
receiving messages. The easiest way to create a pipe is to use
42+
`pipes::stream`. Imagine we wish to perform two expensive
43+
computations in parallel. We might write something like:
44+
45+
~~~~
46+
use task::spawn;
47+
use pipes::{stream, Port, Chan};
48+
49+
let (chan, port) = stream();
50+
51+
do spawn {
52+
let result = some_expensive_computation();
53+
chan.send(result);
54+
}
55+
56+
some_other_expensive_computation();
57+
let result = port.recv();
58+
59+
# fn some_expensive_computation() -> int { 42 }
60+
# fn some_other_expensive_computation() {}
61+
~~~~
62+
63+
Let's walk through this code line-by-line. The first line creates a
64+
stream for sending and receiving integers:
65+
66+
~~~~ {.ignore}
67+
# use pipes::stream;
68+
let (chan, port) = stream();
69+
~~~~
70+
71+
This port is where we will receive the message from the child task
72+
once it is complete. The channel will be used by the child to send a
73+
message to the port. The next statement actually spawns the child:
74+
75+
~~~~
76+
# use task::{spawn};
77+
# use comm::{Port, Chan};
78+
# fn some_expensive_computation() -> int { 42 }
79+
# let port = Port();
80+
# let chan = port.chan();
81+
do spawn {
82+
let result = some_expensive_computation();
83+
chan.send(result);
84+
}
85+
~~~~
86+
87+
This child will perform the expensive computation send the result
88+
over the channel. (Under the hood, `chan` was captured by the
89+
closure that forms the body of the child task. This capture is
90+
allowed because channels are sendable.)
91+
92+
Finally, the parent continues by performing
93+
some other expensive computation and then waiting for the child's result
94+
to arrive on the port:
95+
96+
~~~~
97+
# use pipes::{stream, Port, Chan};
98+
# fn some_other_expensive_computation() {}
99+
# let (chan, port) = stream::<int>();
100+
# chan.send(0);
101+
some_other_expensive_computation();
102+
let result = port.recv();
103+
~~~~
104+
105+
# Creating a task with a bi-directional communication path
106+
107+
A very common thing to do is to spawn a child task where the parent
108+
and child both need to exchange messages with each other. The
109+
function `std::comm::DuplexStream()` supports this pattern. We'll
110+
look briefly at how it is used.
111+
112+
To see how `spawn_conversation()` works, we will create a child task
113+
that receives `uint` messages, converts them to a string, and sends
114+
the string in response. The child terminates when `0` is received.
115+
Here is the function that implements the child task:
116+
117+
~~~~
118+
# use std::comm::DuplexStream;
119+
# use pipes::{Port, Chan};
120+
fn stringifier(channel: &DuplexStream<~str, uint>) {
121+
let mut value: uint;
122+
loop {
123+
value = channel.recv();
124+
channel.send(uint::to_str(value, 10u));
125+
if value == 0u { break; }
126+
}
127+
}
128+
~~~~
129+
130+
The implementation of `DuplexStream` supports both sending and
131+
receiving. The `stringifier` function takes a `DuplexStream` that can
132+
send strings (the first type parameter) and receive `uint` messages
133+
(the second type parameter). The body itself simply loops, reading
134+
from the channel and then sending its response back. The actual
135+
response itself is simply the strified version of the received value,
136+
`uint::to_str(value)`.
137+
138+
Here is the code for the parent task:
139+
140+
~~~~
141+
# use std::comm::DuplexStream;
142+
# use pipes::{Port, Chan};
143+
# use task::spawn;
144+
# fn stringifier(channel: &DuplexStream<~str, uint>) {
145+
# let mut value: uint;
146+
# loop {
147+
# value = channel.recv();
148+
# channel.send(uint::to_str(value, 10u));
149+
# if value == 0u { break; }
150+
# }
151+
# }
152+
# fn main() {
153+
154+
let (from_child, to_child) = DuplexStream();
155+
156+
do spawn || {
157+
stringifier(&to_child);
158+
};
159+
160+
from_child.send(22u);
161+
assert from_child.recv() == ~"22";
162+
163+
from_child.send(23u);
164+
from_child.send(0u);
165+
166+
assert from_child.recv() == ~"23";
167+
assert from_child.recv() == ~"0";
168+
169+
# }
170+
~~~~
171+
172+
The parent task first calls `DuplexStream` to create a pair of bidirectional endpoints. It then uses `task::spawn` to create the child task, which captures one end of the communication channel. As a result, both parent
173+
and child can send and receive data to and from the other.

0 commit comments

Comments
 (0)