oxidecomputer / cancel-safe-futures Goto Github PK

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Pending Approval

These branches will be created by Renovate only once you click their checkbox below.

• Update Rust crate anyhow to 1.0.86
• Update Rust crate futures to 0.3.30
• Update Rust crate futures-core to 0.3.30
• Update Rust crate futures-sink to 0.3.30
• Update Rust crate futures-util to 0.3.30
• Update Rust crate pin-project-lite to 0.2.14
• Update Rust crate tokio-test to 0.4.4
• Update Rust crate bytes to 1.6.0
• Update Rust crate tempfile to 3.10.1
• 🔐 Create all pending approval PRs at once 🔐

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• Pin dependencies

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update Swatinem/rust-cache digest to 23bce25
• Update actions/checkout digest to a5ac7e5
• Update codecov/codecov-action digest to ab904c4
• Update taiki-e/create-gh-release-action digest to 72d65ce
• Update Rust crate tokio to 1.38.0
• Update codecov/codecov-action action to v4
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

@hawkw and I were discussing a Uncancelable<F: FusedFuture> wrapper which runs a future, and spawns a task with the remaining work if the future is dropped before being completed. It is possible to write that, but it ran into several issues:

• It's basically equivalent to eagerly spawning a task.
• It requires the future to be Unpin, so it can be moved out of the Uncancelable future in order to spawn it as a task in the Drop impl. This implies that if the future is an async block, it would need to be eagerly boxed at construction time. So you aren't saving on allocations.
• All the other typical limitations of spawning tasks apply, such that the future must be Send + 'static.

The one advantage is that it would avoid spawning a task if the wrapper is run to completion, but honestly the added complexity doesn't seem worth it.

We should document this in a "negative results" section in the cancel-safe-futures docs.