mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-12-12 13:43:36 +01:00
3a247ca92a
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>
7 lines
367 B
Plaintext
7 lines
367 B
Plaintext
o Major bugfixes (scheduler, consensus):
|
|
- A logic in the code was preventing the scheduler subystem to properly
|
|
make a decision based on the latest consensus when it arrives. This lead
|
|
to the scheduler failing to notice any consensus parameters that might
|
|
change from one consensus to another. Fixes bug 24975; bugfix on
|
|
0.3.2.1-alpha.
|