index.md (2887B)
1 --- 2 title: Tokio Tutorial 3 --- 4 5 https://tokio.rs/tokio/tutorial 6 7 ## Four types of tokio channels: 8 9 ### oneshot channel 10 11 The oneshot channel supports sending a single value from a single producer to a 12 single consumer. This channel is usually used to send the result of a 13 computation to a waiter. 14 15 ### mpsc channel 16 17 The mpsc channel supports sending many values from many producers to a single 18 consumer. This channel is often used to send work to a task or to receive the 19 result of many computations. 20 21 ### broadcast channel 22 23 The broadcast channel supports sending many values from many producers to many 24 consumers. Each consumer will receive each value. This channel can be used to 25 implement “fan out” style patterns common with pub / sub or “chat” systems. 26 27 ### watch channel 28 29 The watch channel supports sending many values from many producers to many 30 consumers. However, only the most recent value is stored in the channel. 31 Consumers are notified when a new value is sent, but there is no guarantee that 32 consumers will see all values. 33 34 https://tokio.rs/tokio/tutorial/channels 35 36 https://docs.rs/tokio/1.49.0/tokio/sync/ 37 38 ## Concepts 39 40 ### Tokio Tasks 41 42 Tasks are the unit of execution managed by the scheduler. Spawning the task 43 submits it to the Tokio scheduler, which then ensures that the task executes 44 when it has work to do. The spawned task may be executed on the same thread as 45 where it was spawned, or it may execute on a different runtime thread. The task 46 can also be moved between threads after being spawned. 47 48 Tasks in Tokio are very lightweight. Under the hood, they require only a single 49 allocation and 64 bytes of memory. Applications should feel free to spawn 50 thousands, if not millions of tasks. 51 52 https://tokio.rs/tokio/tutorial/spawning 53 54 ### Actors 55 56 Nothing in the actor model requires that each actor is its own thread. To the 57 contrary, most actor systems suggest that there should be a large number of 58 actors, and so each actor should map to a task rather than a thread. After all, 59 actors require exclusive access to their wrapped resources only when they 60 execute, and do not care whether they are on a thread of their own or not. In 61 fact, very frequently, the actor model is used in conjunction with the worker 62 pool model—for example, an application that uses the multi- threaded 63 asynchronous runtime Tokio can spawn an asynchronous task for each actor, and 64 Tokio will then make the execution of each actor a job in its worker pool. Thus, 65 the execution of a given actor may move from thread to thread in the worker pool 66 as the actor yields and resumes, but every time the actor executes it maintains 67 exclusive access to its wrapped resource. 68 69 (Excerpt from Rust for Rustaceans) 70 71 ## Examples 72 73 Beginner's Guide to Concurrent Programming: Coding a Multithreaded Chat Server 74 using Tokio: 75 76 https://github.com/pretzelhammer/rust-blog/blob/master/posts/chat-server.md