Skip to content

Conversation

ariaandika
Copy link
Contributor

Allows returning an owned notification future that can be moved across threads. Inspired by #7231. Continuing from #7391

Motivation

The Notify api returns Notified<'_> Future for the non-blocking wait of But having a lifetime makes it hard to use in Future since it requires self referencing lifetime.

In most if not all use cases, even in the example, the Notify will be wrapped in an Arc, so having an owned version will eliminate lifetime requirement.

Other use case mentioned in #7391 is to launch tasks and then notify them at the same time using notify_waiters.

let n = Arc::new(Notify::new()); // We can't use notified here because we need to send it.

tokio::spawn({
  let n = n.clone();
  async move {
    // if we need the code to be correct we need to register the waiter here
    tokio::sleep(10).await;
    n.notified().await;
    println!("event received");
}})

n.notify_waiters();

Solution

Introduced new a type NotifiedOwned, a Future that holds Arc instead of shared reference to Notify, eliminating lifetime requirement. Add corresponding Notify::notified_owned. The new method can only be called if self is within an Arc.

Extract the `Notified::poll_notified` and `Notified::drop` logic into a
function. Add `NotifiedOwned` and `Notify::notified_owned`.
@github-actions github-actions bot added the R-loom-sync Run loom sync tests on this PR label Jul 18, 2025
@ADD-SP ADD-SP added C-enhancement Category: A PR with an enhancement or bugfix. A-tokio Area: The main tokio crate M-sync Module: tokio/sync labels Jul 19, 2025
Copy link
Member

@ADD-SP ADD-SP left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you write some tests for this new feature?

@ADD-SP ADD-SP changed the title feat: introduce NotifiedOwned sync: introdue sync::Notify::notified_own() Jul 19, 2025
@ADD-SP ADD-SP changed the title sync: introdue sync::Notify::notified_own() sync: introdue sync::Notify::notified_owned() Jul 19, 2025
@ariaandika
Copy link
Contributor Author

I did not know about loom arbitrary_self_types feature is, and considering the error help message, changing notified_owned to take self: Arc<Self> means callers must have the ownership of Arc<Notify>, though callers can just .clone() before calling notified_owned, which in my opinion is slightly inconvenient.

Should i proceed ?

@Darksonn
Copy link
Contributor

Darksonn commented Jul 19, 2025

Do not enable the arbitrary_self_types feature. We can skip using the loom Arc, but anything else in sync should come from Loom.

@Darksonn
Copy link
Contributor

And yes you should take self: Arc<Self> instead of forcing a clone of the Arc on the end-user even if one is not needed.

Copy link
Member

@ADD-SP ADD-SP left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks good to me.

Copy link
Member

@ADD-SP ADD-SP left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation looks good to me, could you add some tests in tokio/tests/sync_notify.rs?

@ariaandika
Copy link
Contributor Author

The underlying logic is exactly the same, is additional tests necessary ?

Also, is it okay if i just copied from existing tests of Notfied<'_> ? I don't know special test case for an owned version.

Copy link
Member

@ADD-SP ADD-SP left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The underlying logic is exactly the same, is additional tests necessary ?

I think additional tests are necessary as we may (not likely) to change the implementation in the future, so we might have different implementation.

In principle, tests under tokio/tests are black box tests, which should not care about the implementation details too much.

I don't know special test case for an owned version.

I think the only special case is that make sure the OwnedNotified is 'static because this is the whole point of this feature.

I guess this is just my personal flavor, it should be easy to eyeball if a type is 'static or not, seems we don't need a test to cover this.

is it okay if i just copied from existing tests of Notfied<'_> ?

Apparently, we don't want to copy such a large test code, Let me think a little bit. Feel free to share you through about this in here.

@ariaandika
Copy link
Contributor Author

Well, looking on the other API, Semaphore, the tests between sync_semaphore.rs and sync_semaphore_owned.rs is pretty similar, one just swap the Semaphore::acquire and Semaphore::acquire_owned.

@ADD-SP
Copy link
Member

ADD-SP commented Jul 23, 2025

Well, looking on the other API, Semaphore, the tests between sync_semaphore.rs and sync_semaphore_owned.rs is pretty similar, one just swap the Semaphore::acquire and Semaphore::acquire_owned.

I didn't come up with a better idea, I think it is ok to follow the approach of sync_semaphore_owned.rs.

Copy link
Member

@ADD-SP ADD-SP left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, thanks!

@ariaandika
Copy link
Contributor Author

You're welcome, glad the feature can be added.

@ADD-SP ADD-SP merged commit d545aa2 into tokio-rs:master Jul 26, 2025
86 checks passed
@ariaandika ariaandika deleted the aria/notified_owned branch July 27, 2025 10:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tokio Area: The main tokio crate C-enhancement Category: A PR with an enhancement or bugfix. M-sync Module: tokio/sync R-loom-sync Run loom sync tests on this PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants