Context and Waker might be accidentally Sync · Issue #66481 · rust-lang/rust (original) (raw)

One issue that came up in the discussion here is that the Context type implements Send + Sync.

This might have been introduced accidentally. Send probably does not matter at all, given that users will only observe a Context by reference. However Sync has the impliciation that we will not be able to add non thread-safe methods to Context - e.g. in order to optimize thread-local wake-ups again.

It might be interesting to see whether Send and Sync support could be removed from the type. Unfortunately that is however a breaking change - even though it is not likely that any code currently uses Context out of the direct poll() path.

In a similar fashion it had been observed in the implementation of #65875 (comment) that the Waker type is also Send and Sync. While it had been expected for Send- given that Wakers are used to wake-up tasks from different threads, it might not have been for Sync. One downside of Wakers being Sync is that it prevents optimizations. E.g. in linked ticket the original implementation contained an optimization that while a Waker was not cloned (and thereby equipped with a different vtable) it could wake-up the local eventloop again by just setting a non-synchronized boolean flag in the current thread. However given that &Waker could be transferred to another thread, and .wake_by_ref() called from there even within the .poll() context - this optmization is invalid.

Here it would also be interesting if the Sync requirement could be removed. I expect the amount of real-world usages to be in the same ballpark as sending &Context across threads - hopefully 0.
But it's again a breaking change 😢

cc @Ralith , @Nemo157 , @cramertj , @withoutboats