GNOME Bugzilla – Bug 708694
qdata for main contexts
Last modified: 2018-05-24 15:42:33 UTC
We have these two commonly used patterns in GIO: - creating objects that emit signals to the thread-default main context - singleton objects that emit signals Occasionally we combine these two for a semi-singleton there we have one object per-context that emits signals into that context. Keeping track of these semi-singletons typically involves some sort of hashtable keyed by main context, protected using locking primatives (due to the somewhat obvious threadsafety requirements implied by your support of multiple main contexts). This is possible using our new weakrefs, but it is not the easiest thing to do. A nice alternative to having a global hashtable keyed by some object is to have qdata on the object itself. This would substantially simplify the implementation of any of these sorts of semi-singleton objects.
Created attachment 256393 [details] [review] GMainContext: add qdata
Can you just give one or two examples? And an example patch for a consumer inside GLib would be helpful.
Created attachment 256396 [details] [review] Add GAppInfoMonitor This is a simple object that emits a "change" signal when the installed applications may have changed in some way.
Here's an example consumer that will be merged to GLib soon...
I'm starting to go slightly sour on this bug based on the fact that I actually hate qdata being based on Quarks. We should consider something more like the cairo approach of using a unique pointer.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/760.