Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • BIND BIND
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 525
    • Issues 525
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 95
    • Merge requests 95
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source Projects
  • BINDBIND
  • Issues
  • #547
Closed
Open
Created Sep 20, 2018 by Evan Hunt@eachOwner0 of 1 task completed0/1 task

Initial implementation of modules doesn't support multiple instances

The following discussion from !632 (closed) should be addressed:

  • @michal started a discussion: (+1 comment)

    As for commit 882a62c6, I am afraid it does not solve another high-level issue that has only occurred to me just now: it is impossible to use two instances of a given hook module in separate views, which kind of renders the concept of per-view hook tables bogus :(

    I would consider reverting 882a62c6 and moving to a more complex model that would solve both issues. An example would be:

    • track modules currently in use using a server-wide list; each element in that list would be a reference-counted structure representing a single shared object mapped using dlopen() (that can be released once its reference count drops to 0),
    • introduce hook instances (hey, remember b7a25260? ;)), i.e. make every hook statement present in a configuration grab a reference to the module structure from the previous bullet point and make sure it acts independently from any other hook statements,
    • use instance-specific configuration and data tables in modules,
    • keep per-view lists of hook instances currently registered in that view's hook table.

    I know this hurts, but I do not think we can defend the current approach in the long run due to its very limited flexibility.

    Perhaps we should consider implementing this in a follow-up MR rather than right now. In any case, I think we should address this before making a release with hooks available.

Edited Sep 25, 2018 by Michał Kępień
Assignee
Assign to
Time tracking