Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • Kea Kea
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 513
    • Issues 513
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 48
    • Merge requests 48
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source Projects
  • KeaKea
  • Issues
  • #1719

Closed
Open
Created Feb 22, 2021 by Andrei Pavel@andrei🐧Maintainer2 of 2 tasks completed2/2 tasks

DB_LOG_* macros have a leaking lock

The lock should not leak outside the macro because that would make macros not callable twice inside the same scope and in all downstream functions. That would lead to a deadlock. Even though this is probably not going to occur because as we've done unitl now, we log once per function and these functions return imeddiately, this might not seem intuitive for further use.

Suggestion:

  • Make a way to limit lock scope, maybe curly brackets inside the macro to limit it's scope to itself or maybe a template with variadic arguments.
  • Add a unit test that will test that the mutex is not taken after calling this macro.

Derived from #1711 (closed)

Edited Feb 22, 2021 by Andrei Pavel
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking