From fbe7fce491ea37b63890fd36498f92a6dc2652d0 Mon Sep 17 00:00:00 2001 From: cf Date: Sat, 25 Jan 2020 11:02:13 +0000 Subject: [PATCH] GitBook: [master] one page modified --- reader-excercises.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/reader-excercises.md b/reader-excercises.md index e706815..c3d3c6c 100644 --- a/reader-excercises.md +++ b/reader-excercises.md @@ -22,7 +22,7 @@ Next , using a `Mutex` as a synchonization mechanism might be overkill since man * Could you use any of the synchonization mechanisms in [Crossbeam](https://github.com/crossbeam-rs/crossbeam)? * Do you want to dig into [atomics in Rust and implement a synchonization mechanism](https://cfsamsonbooks.gitbook.io/epoll-kqueue-iocp-explained/appendix-1/atomics-in-rust) of your own? -### Creating a new Waker for every event +### Avoid creating a new Waker for every event Right now we create a new instance of a Waker for every event we create. Is this really needed? @@ -32,7 +32,7 @@ Right now we create a new instance of a Waker for every event we create. Is this ### Could we implement more methods on our executor? -What about CPU intensice tasks? Right now they'll prevent our executor thread from progressing an handling events. Could you create a thread pool and create a method to send such tasks to the threadpool instead and make it wake you up when done? +What about CPU intensice tasks? Right now they'll prevent our executor thread from progressing an handling events. Could you create a thread pool and create a method to send such tasks to the threadpool instead together with a Waker which will wake up the executor thread once the CPU intensive task is done? In both `async_std` and `tokio` this method is called `spawn_blocking`, a good place to start is to read the documentation and the code thy use to implement that.