Skip to content

Merging futures-timer into this repository. #2951

Not planned
@carloskiki

Description

@carloskiki

I believe the futures-timer crate is now unmaintained since it is housed under the async-rs group (which stopped maintaining async-std).

It would be awesome if we could fork it in this repository. I find it hard to believe that this is the only timer library which does not bring extra dependencies, but I simply can't find another one. I hope we can keep maintaining it for this reason.

I can open a PR if the maintainers are in favour of this.

Activity

seanmonstar

seanmonstar commented on Apr 25, 2025

@seanmonstar
Contributor

I'm no longer a maintainer here, but generally (IMO) there isn't enough maintainer time for what already is here, and less and less from wg-async, so I'd find it hard to adopt another crate into this repo.

That said, you could always fork the timers crate and maintain it. That's the beauty of open source :)

taiki-e

taiki-e commented on Apr 25, 2025

@taiki-e
Member

I'm effectively the only current maintainer of futures-rs (although wg-async also has access), but since I'm also involved in the maintenance of tokio and smol, I'm honestly not very interested in adding and maintaining new utilities that are also already provided by tokio and smol, to futures-rs. (Aside from the case of adding methods to extension traits.)

Also note that futures-timer has been almost unmaintained for the last five years, as is obvious from the commit history.

Therefore, I would recommend the use of tokio or smol (or async-io which actually implements smol's timer) timers.

the only timer library which does not bring extra dependencies

I'm not claiming that this particular library is problematic, but in my experience, you usually have to be very careful with async-related libraries that have no dependencies (especially those that claim it as an advantage). This is especially true when there is unsafe code around pinning.

It is very hard to manually write unsafe code around pinning (instead of using pin-project/pin-project-lite), and even people familiar with async Rust or unsafe Rust can easily write unsound or error-prone or inefficient code. And those who are not enough aware of this fact tend to claim “no dependencies at all, unlike other (well-reviewed) crates” as an advantage of their crate.

FYI, the following is a non-exhaustive list of such mistakes that I have found in my reviews:

#2452 (review)
#2851 (comment)
rust-lang/rust#111347 (review)
tokio-rs/tokio#2612
async-rs/async-std#903
smol-rs/event-listener#50 (comment)
smol-rs/async-lock#36 (comment)
smol-rs/futures-lite#15 (comment)
ardaku/pasts#3

(futures-micro and pasts linked in the last two are not so well-known, but they ware precisely the ones that “claim the no dependencies as an advantage, and there actually have been unsoundness regarding pinning in the past (already fixed AFAIK)”.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @seanmonstar@taiki-e@carloskiki

        Issue actions

          Merging `futures-timer` into this repository. · Issue #2951 · rust-lang/futures-rs