Conclusion and exercises

Congratulations. Good job! If you got this far you must have stayed with me all the way. I hope you enjoyed the ride!

Remember that you call always leave feedback, suggest improvements or ask questions in the issue_tracker for this book. I'll try my best to respond to each one of them.

I'll leave you with some suggestions for exercises if you want to explore a little further below.

Until next time!

Reader exercises

So our implementation has taken some obvious shortcuts and could use some improvement. Actually digging into the code and try things yourself is a good way to learn. Here are some good exercises if you want to explore more:

Avoid `thread::park`

The big problem using Thread::park and Thread::unpark is that the user can access these same methods from their own code. Try to use another method to suspend our thread and wake it up again on our command. Some hints:

Check out CondVars, here are two sources Wikipedia and the docs for CondVar
Take a look at crates that help you with this exact problem like Crossbeam (specifically the Parker)

Avoid wrapping the whole `Reactor` in a mutex and pass it around

First of all, protecting the whole Reactor and passing it around is overkill. We're only interested in synchronizing some parts of the information it contains. Try to refactor that out and only synchronize access to what's really needed.

I'd encourage you to have a look at how the async_std driver is implemented and how tokios scheduler is implemented to get some inspiration.

Do you want to pass around a reference to this information using an Arc?
Do you want to make a global Reactor so it can be accessed from anywhere?

Building a better exectuor

Right now, we can only run one and one future. Most runtimes has a spawn function which let's you start off a future and await it later so you can run multiple futures concurrently.

As I suggested in the start of this book, visiting @stjepan'sblog series about implementing your own executors is the place I would start and take it from there.

Futures Explained in 200 Lines of Rust

Conclusion and exercises

Reader exercises

Avoid `thread::park`

Avoid wrapping the whole `Reactor` in a mutex and pass it around

Building a better exectuor

Further reading

Futures Explained in 200 Lines of Rust

Conclusion and exercises

Reader exercises

Avoid thread::park

Avoid wrapping the whole Reactor in a mutex and pass it around

Building a better exectuor

Further reading

Avoid `thread::park`

Avoid wrapping the whole `Reactor` in a mutex and pass it around