The original explanation of Wakers sort-of implied that there was
exactly one Waker for all futures (each executor creates one, then
passes clones of that to all registered futures). The new phrasing
makes it clear that isn't the case. Also added another couple of
paragraphs to the conclusion to really expand on that.
when two tasks is given the same id.
The explicit close call is not needed. We can do that in the `Drop`
implementation instead. It's better to have accounting tasks like this
only one place and it didn't add anything to the example.
There is a subtle bug which occurs if two tasks are given the same Id.
I mentioned this explicitly since it's such an easy thing to do. I
added the fix as a reader excercise since for the examples sake I think
it's better to pass them in explicitly so that we don't "pollute" the
example with more code than strictly needed to get an understanding of
futures.
The problems addressed in the earlier version led to an "incorrect"
example which is bad to pass along after reading a whole book. after
getting some feedback in #2 i decided to show how we can create a
proper `Parker`.
The main example (which I assume most interested readers will copy) now
uses a proper parking thechnique so there should be no more dataraces
left.
I also removed the "Reader Excercise" paragraph suggesting that they
explore a way to implement proper parking since we now show that in
our main example.
