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
  • !2

Engine: Do not emit optimistic change notifications unless the local value is different

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Daniel Playfair Cal requested to merge daniel.playfair.cal/dconf:patch/engine-check into master Jul 09, 2018
  • Overview 38
  • Commits 6
  • Pipelines 21
  • Changes 9

Depends on !59 (merged)

Currently when using the optimistic "fast" API, when a client requests a write to the database, changed signals are emitted to the clients of the engine process even if the writes did not result in the engine process's copy of the database changing values.

This results in infinite loops when client code such as gnome-shell and extensions perform writes as a result of changed notifications without checking if the new value is different from the old value. For example, it causes bugs like this: https://bugzilla.gnome.org/show_bug.cgi?id=782688

Client code can avoid this problem by keeping a reference to the current value of any watched setting and not performing writes as a result of changed signals when the new value is the same as the old value. This is impractical to fix (there are hundreds of places in gnome-shell and various extensions which do this). It is also a problem that if a single shell extension that does not perform this optimisation, the entire shell goes into an infinite loop and hangs or crashes. The changed signal should not be sent in the first place unless they key has changed, and developers working with high level languages such as Javascript should not be responsible for handling the consequences of race conditions in multithreaded C code.

This change still sends the write request to the writer service in all cases, but does not emit local optimistic changed signals unless the changeset results in some value in the database being different to what it previously was. This breaks the infinite loops while still preserving the ability of the writer process/DBus to serialize all writes (and possibly still emit changed signals if the canonical copy of the database is changed by the write).

See existing discussion on bugzilla here: https://bugzilla.gnome.org/show_bug.cgi?id=789639

Edited May 05, 2020 by Daniel Playfair Cal
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: patch/engine-check