-
Notifications
You must be signed in to change notification settings - Fork 409
Potential deadlock in rx-runloop #487
Copy link
Copy link
Open
Description
While inspecting rx-runloop.hpp I noticed there might be a potential deadlock in the code:
RxCpp/Rx/v2/src/rxcpp/schedulers/rx-runloop.hpp
Lines 77 to 88 in aac2fc9
| virtual void schedule(clock_type::time_point when, const schedulable& scbl) const { | |
| if (scbl.is_subscribed()) { | |
| auto st = state.lock(); | |
| std::unique_lock<std::mutex> guard(st->lock); | |
| const bool need_earlier_wakeup_notification = st->notify_earlier_wakeup && | |
| (st->q.empty() || when < st->q.top().when); | |
| st->q.push(detail::run_loop_state::item_type(when, scbl)); | |
| st->r.reset(false); | |
| if (need_earlier_wakeup_notification) st->notify_earlier_wakeup(when); | |
| guard.unlock(); // So we can't get attempt to recursively lock the state | |
| } | |
| } |
Last two lines appear to be flipped, guard.unlock() is a no-op if it's at the end of a scope. During notify_earlier_wakeup it could call back into the runloop and take another lock which would hang since these locks aren't recursive.
/***/ if (need_earlier_wakeup_notification) st->notify_earlier_wakeup(when);
/***/ guard.unlock(); // So we can't get attempt to recursively lock the stateReactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels