LocalWaker and Waker cleanups

[cramertj]

r? @aturon

[TimNN]

Ping from triage @aturon / @rust-lang/libs: This PR requires your review.

[aturon]

Is this actually safe? With scoped threads it seems like you could use this to pass a LocalWaker to another thread as a &Waker?

[cramertj]

Yep, you can! And that's totally safe, because you can only call .wake() on the inner UnsafeWake in a Wake-- you can't call .wake_local().

[aturon]

@bors r+

[bors]

📌 Commit 00e0565 has been approved by aturon

[bors]

⌛ Testing commit 00e0565 with merge 5af0bb8...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: aturon
Pushing 5af0bb8 to master...

[ghost]

@cramertj Bikeshedding... 🚲🚲🚲

I find names will_wake, will_wake_local, and will_wake_nonlocal confusing. Aren't those functions essentially just equality tests? Why not implement Eq for Waker and LocalWaker?

Compare: waker.will_wake_local(local_waker) vs waker == local_waker.

[cramertj]

@stjepang There was a lot of debate back in the day about this, which ended in rust-lang/futures-rs#689 and rust-lang/futures-rs#1236, in an effort to prevent people from thinking of two different Tasks as being "equivalent" merely because their notify() methods wake the same top-level future. With the addition of LocalWaker, it's also kind of wrong to consider them "equivalent" since they may perform different behaviors, but will result in waking up the same task (however, this doesn't actually work today since will_wake checks for equality of the fat pointers and so has false negatives).

[ghost]

@cramertj Ah I see the problem, thanks for the explanation!

Still, judging by the name, I had no idea what a.will_wake(b) actually does. My intuition was that there's some kind of promise that a will wake b in the future, but that's not the case.