v1.9.0

[notgull]

• Re-introduce the thread-local task push optimization to the executor. (Use actual thread local queues instead of using a RwLock #93)
• Bump async-task to v4.4.0. (minimum supported async-task version is 4.4.0 #90)
• Replace some unnecessary atomic operations with non-atomic operations. (Replace unnecessary atomics with non-atomic operations #94)
• Use weaker atomic orderings for notifications. (Weaken the atomic orderings for notification #95)
• When spawning a future, avoid looking up the ID to assign to that future twice. (Avoid redundant lookups in the active slab when spawning new tasks #96)

[taiki-e]

• Use weaker atomic orderings for notifications.

I haven't seen the relevant code yet, but I think notifications are usually preferable to having SeqCst semantics, does this change that semantics?
https://docs.rs/event-listener/latest/event_listener/trait.IntoNotification.html#method.relaxed

Usually, notifications emit a SeqCst atomic fence before any listeners are woken up. This ensures that notification state isn’t inconsistent before any wakers are woken up.

[notgull]

I haven't seen the relevant code yet, but I think notifications are usually preferable to having SeqCst semantics, does this change that semantics? https://docs.rs/event-listener/latest/event_listener/trait.IntoNotification.html#method.relaxed

The actual notification data structure (the Sleepers structure in this instance) is secured by a Mutex. So by my count the current SeqCst ordering is redundant, as:

• The Release ordering of releasing the Mutex guard should ensure that the store to notified is kept ordered when it is stored.
• The AcqRel ordering of swapping out the notified atomic shouldn't be problematic as it is synchronized with the Release ordering of setting the value to true.

In addition, AtomicWaker uses similar orderings, so I think it should be fine.

cc @james7132, this is your change, you might have a better mental model of what's happening here.

[james7132]

The way that I saw it was that it was more acting as an early-out in the case there are multiple notifications going off while a notified thread isn't fully awake yet. In that case, the Acquire and Release orderings are sufficient to act as a lock, in the exact way that @notgull covered. If that's the wrong mental model for how that should be working, then it should be reverted.

[taiki-e]

Thanks for the clarification!

[notgull]

Given the new changes on master I've elected to make this a minor version bump.