Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • D dconf
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 47
    • Issues 47
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 3
    • Merge requests 3
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and 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
  • GNOMEGNOME
  • dconf
  • Merge requests
  • !1

Engine: track in progress watch handles to avoid spurious changed signals for the root path

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Daniel Playfair Cal requested to merge daniel.playfair.cal/dconf:patch/ow into master Jul 09, 2018
  • Overview 1
  • Commits 8
  • Pipelines 0
  • Changes 3

When using the optimistic returning "fast" API, there is a case where a "changed" notification is emitted for the root path "/". This occurs as a result of the following sequence of events:

  1. The client subscribes to at least any path
  2. The engine returns immediately indicating to the client that the path is being watched, before it actually establishes a watch such that it will receive a message form the writer process when the relevant path changes.
  3. Some unrelated change is made to the database
  4. The watch request succeeds and the engine process receives a message indicating that the subscription has been created. At this point, the engine process cannot tell if it has failed to emit a changed notification to its clients, because something changed in the database in the time between when its client thought it was subscribed and when the engine process was actually subscribed. So, it emits a changed notification for the entire database, most of which has probably not changed.

This causes infinite loops and other intermittent and difficult to debug issues in client code such as gnome-shell and extensions. Changed signals cause subscription requests and subscription requests cause changed signals. Notably, it makes it impossible to run gnome-shell in valgrind, which complicates debugging memory issues.

Subscription requests should not cause changed signals, since they do not change the contents of the database.

The fix here makes the following changes:

  • The engine stores a set of paths for which it has an active or pending subscription to
  • If a client requests to subscribe to a path which the engine is already subscribed to, it does not subscribe to it a second time. This breaks the infinite loops, since clients generally only subscribe to a constant set of paths. The spurious change signals can now only happen before the first subscription completes.
  • When a subscription confirmation message is received by the engine and the database has changed since the client was told the subscription was established, change notifications are sent only for the path being subscribed to, not for the root path.

There's an existing discussion on bugzilla here: https://bugzilla.gnome.org/show_bug.cgi?id=790640

Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: patch/ow