-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
sync: introdue sync::Notify::notified_owned()
#7465
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Extract the `Notified::poll_notified` and `Notified::drop` logic into a function. Add `NotifiedOwned` and `Notify::notified_owned`.
There was a problem hiding this 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?
NotifiedOwned
sync::Notify::notified_own()
sync::Notify::notified_own()
sync::Notify::notified_owned()
I did not know about loom Should i proceed ? |
Do not enable the |
And yes you should take |
There was a problem hiding this 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.
There was a problem hiding this 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
?
The underlying logic is exactly the same, is additional tests necessary ? Also, is it okay if i just copied from existing tests of |
There was a problem hiding this 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.
Well, looking on the other API, |
I didn't come up with a better idea, I think it is ok to follow the approach of |
There was a problem hiding this 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!
You're welcome, glad the feature can be added. |
Allows returning an owned notification future that can be moved across threads. Inspired by #7231. Continuing from #7391
Motivation
The
Notify
api returnsNotified<'_>
Future for the non-blocking wait of But having a lifetime makes it hard to use inFuture
since it requires self referencing lifetime.In most if not all use cases, even in the example, the
Notify
will be wrapped in anArc
, 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
.Solution
Introduced new a type
NotifiedOwned
, aFuture
that holdsArc
instead of shared reference toNotify
, eliminating lifetime requirement. Add correspondingNotify::notified_owned
. The new method can only be called ifself
is within anArc
.