Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #24649

Closed (moved)
(moved)
Open
Created Dec 17, 2017 by Nick Mathewson@nickm🍬

Simplify bridge code: do we still need mark-unmark-and-sweep logic?

In an older version of the bridge code, we would encode some state information in the bridge_info_t object. Therefore, when we reloaded the configuration, it was important that we use the old object for any bridges that we still had. For that reason, we would (on reloading the configuration) first mark all bridges, then unmark any bridges that were still in the configuration (while adding any new bridges), and finally we'd free all the marked bridges.

But, looking at the code now, it appears we no longer take this approach: once marked_for_removal is set on a bridge, nothing clears it. If that's the case, we could simplify our bridge configuration logic a bit by just clearing the bridge list and rebuilding it, and dropping this whole "marked_for_removal" business.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking