Fix another race in Notification Queue

Summary: Consider a case we found that the queue is empty and unlocked and before our setActive(false) from SCOPE_EXIT gets called (or gets the lock) putMessageImpl got the lock. Now putMessage thinks that we donot want to add another signal but actually we do.

Test Plan:
Running mcreplay2 without running into this problem on a box.
Benchmark:

Reviewed By: davejwatson@fb.com

FB internal diff: D1428249

diff --git a/folly/io/async/NotificationQueue.h b/folly/io/async/NotificationQueue.h
index d0afd3e414e3d166f86f8ed42cc0e7ea4dc4fdc5..c06f3e846e2b4c0426f140ea4383ee033681de69 100644 (file)
--- a/folly/io/async/NotificationQueue.h
+++ b/folly/io/async/NotificationQueue.h
@@ -576,6 +576,7 @@ void NotificationQueue<MessageT>::Consumer::handlerReady(uint16_t events)
     try {
       if (UNLIKELY(queue_->queue_.empty())) {
         // If there is no message, we've reached the end of the queue, return.
+        setActive(false);
         queue_->spinlock_.unlock();
         return;
       }