Fix (and test) `Future` creation after a `Notifier` was notified

After a `Notifier` has been `notify`'d, attempts to `get_future`
should return a `Future` which is pre-completed, however this was
not the case.

This commit simply fixes the behavior, adding a test to demonstrate
the issue.

diff --git a/lightning/src/util/wakers.rs b/lightning/src/util/wakers.rs
index 166771948fad62bc2f10078b5360fb67207f50f5..e55ba37ffd84c99ba19ddc625a5cfa7e9f23ed56 100644 (file)
--- a/lightning/src/util/wakers.rs
+++ b/lightning/src/util/wakers.rs
@@ -103,7 +103,7 @@ impl Notifier {
                        Future {
                                state: Arc::new(Mutex::new(FutureState {
                                        callbacks: Vec::new(),
-                                       complete: false,
+                                       complete: true,
                                }))
                        }
                } else if let Some(existing_state) = &lock.1 {
@@ -217,6 +217,20 @@ mod tests {
        use core::future::Future as FutureTrait;
        use core::task::{Context, Poll, RawWaker, RawWakerVTable, Waker};
 
+       #[test]
+       fn notifier_pre_notified_future() {
+               // Previously, if we generated a future after a `Notifier` had been notified, the future
+               // would never complete. This tests this behavior, ensuring the future instead completes
+               // immediately.
+               let notifier = Notifier::new();
+               notifier.notify();
+
+               let callback = Arc::new(AtomicBool::new(false));
+               let callback_ref = Arc::clone(&callback);
+               notifier.get_future().register_callback(Box::new(move || assert!(!callback_ref.fetch_or(true, Ordering::SeqCst))));
+               assert!(callback.load(Ordering::SeqCst));
+       }
+
        #[cfg(feature = "std")]
        #[test]
        fn test_wait_timeout() {