Commit Graph

3 Commits

Author SHA1 Message Date
David Goulet
fbc455cbd2 ns: Add a before and after consensus has changed notification
In 0.3.2.1-alpha, we've added notify_networkstatus_changed() in order to have
a way to notify other subsystems that the consensus just changed. The old and
new consensus are passed to it.

Before this patch, this was done _before_ the new consensus was set globally
(thus NOT accessible by getting the latest consensus). The scheduler
notification was assuming that it was set and select_scheduler() is looking at
the latest consensus to get the parameters it might needs. This was very wrong
because at that point it is still the old consensus set globally.

This commit changes the notify_networkstatus_changed() to be the "before"
function and adds an "after" notification from which the scheduler subsystem
is notified.

Fixes #24975
2018-01-31 14:15:02 -05:00
David Goulet
c85f78e74c Revert "ns: Call notify_networkstatus_changed() after the new consensus is set globally"
This reverts commit 3a247ca92a.
2018-01-31 13:59:05 -05:00
David Goulet
3a247ca92a ns: Call notify_networkstatus_changed() after the new consensus is set globally
In 0.3.2.1-alpha, we've added this function in order to have a way to notify
other subsystems that the consensus just changed. The old consensus and the
new one are passed to it.

Before this patch, this was done _before_ the new consensus was set globally
(thus NOT accessible by getting the latest consensus). The scheduler
notification was assuming that it was set and select_scheduler() is looking at
the latest consensus to get the parameters it might needs. This was very wrong
because at that point it is still the old consensus set globally.

With this commit, notify_networkstatus_changed() has been moved _after_ the
new consensus is set globally. The main obvious reasons is to fix the bug
described above and in #24975. The other reason is that this notify function
doesn't return anything which could be allowing the possibility of refusing to
set the new consensus on error. In other words, the new consensus is set right
after the notification whatever happens.

It does no harm or change in behavior to set the new consensus first and then
notify the subsystems. The two functions currently used are for the control
port using the old and new consensus and sending the diff. The second is the
scheduler that needs the new consensus to be set globally before being called.

Of course, the function has been documented accordinly to clearly state it is
done _after_ the new consensus is set.

Fixes #24975

Signed-off-by: David Goulet <dgoulet@torproject.org>
2018-01-31 11:21:18 -05:00