Eliza Weisman

Results 637 comments of Eliza Weisman

> What happened to this? I kind of forgot about it; happy to continue working on it if others would find it useful!

IMO, the main benefit for keeping these types private is to reserve the ability to replace them with `async fn`s if/when that becomes possible. I'm less concerned about cluttering the...

Whoops! In that case, the motivation for not exposing the combinators that I mentioned doesn't really apply at all.

> Think this can be closed. `Task` does have an `Id` field now, which can be accessed through `JoinHandle`. Currently, the `JoinHandle` only allows accessing the task ID from _outside_...

Tokio's use of `parking_lot` is an off-by-default optional dependency, so Tokio actually uses `std::sync::Mutex` by default, unless the `parking_lot` feature flag is enabled. However, I agree that it would be...

> Oops, I thought parking_lot was the default. Either way, if std faster I think parking_lot should just be removed entirely. Removing the feature flag is a breaking change. It...

> How does deprecation work? Would the idea be to say the flag is deprecated (AFAIK there's no way to mark a flag as deprecated) and then remove it in...

Yeah, IMO, the only compelling reason to remove the feature is to actually get rid of the need to test another feature combination, which we can't do without a breaking...

> > Increasing our MSRV to 1.63.0 isn't going to happen anytime soon, but it probably will eventually. > > Once this happens, can `tokio`'s `Mutex::new()` become `const` as well,...

I think I agree with Alice; while polling callbacks seem like they could potentially be desirable, if the goal is to add hooks for running occasional maintenance tasks, we should...