Switch PersistenceNotifierGuard persist closure to FnOnce #3835
Conversation
|
👋 Thanks for assigning @tnull as a reviewer! |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3835 +/- ##
==========================================
- Coverage 89.92% 89.84% -0.09%
==========================================
Files 160 160
Lines 129581 129655 +74
Branches 129581 129655 +74
==========================================
- Hits 116525 116485 -40
- Misses 10361 10466 +105
- Partials 2695 2704 +9 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| @@ -2815,10 +2815,10 @@ enum NotifyOption { | |||
| /// We allow callers to either always notify by constructing with `notify_on_drop` or choose to | |||
| /// notify or not based on whether relevant changes have been made, providing a closure to | |||
| /// `optionally_notify` which returns a `NotifyOption`. | |||
There was a problem hiding this comment.
Background question: it seems that in some instances, the persist_check isn't just checking, but also making the actual changes to the chan mgr state. Is that fine, or indicative of the PersistenceNotifierGuard not fully matching its desired use cases?
There was a problem hiding this comment.
In almost all cases it is making actual changes to the internal state, that's how we have the context to know whether we should persist or not via the returned NotifyOption
| @@ -2833,20 +2833,20 @@ impl<'a> PersistenceNotifierGuard<'a, fn() -> NotifyOption> { | |||
| /// isn't ideal. | |||
| fn notify_on_drop<C: AChannelManager>( | |||
| cm: &'a C, | |||
| ) -> PersistenceNotifierGuard<'a, impl FnMut() -> NotifyOption> { | |||
| ) -> PersistenceNotifierGuard<'a, impl FnOnce() -> NotifyOption> { | |||
There was a problem hiding this comment.
So this means that only single-use closure may be provided now. And it seems we are lucky that nowhere a closure was reused, so no other refactoring needed? (questions for me to understand this better)
There was a problem hiding this comment.
Correct, and there should never be a closure reuse given the usage pattern
| fn drop(&mut self) { | ||
| match (self.should_persist)() { | ||
| match (self.should_persist.take().unwrap())() { |
There was a problem hiding this comment.
We should never reach this, but how about avoiding the unwrap and just matching on Some(..)/None?
There was a problem hiding this comment.
Isn't it basically the same? unreachable would also panic in the None case
This allows us to move owned and mutable values into the closure, with the assumption that the closure can only be invoked once. As a result, we now have to track `should_persist` as an `Option`, such that we can `take` the owned closure and invoke it within the `PersistenceNotifierGuard::drop` implementation.
wpaulino
force-pushed
the
persistence-notifier-fn-once
branch
from
a6a43c2 to
bc420a8
Compare
This allows us to move owned and mutable values into the closure, with the assumption that the closure can only be invoked once. As a result, we now have to track
should_persistas anOption, such that we cantakethe owned closure and invoke it within thePersistenceNotifierGuard::dropimplementation.Motivated by #3736 (comment).