GNOME Bugzilla – Bug 616314
Make GSettings (partially) threadsafe
Last modified: 2010-05-18 13:47:16 UTC
Hi, for GStreamer we would need GSettings to be at least partially threadsafe. According the Ryan it currently isn't even possible to read settings from different threads. With GConf this works. Additional to reading settings from different threads it would be nice if watches for setting changes could use a non-default main context but that's less important for now.
This will definitely be supported.
yesterday i checked in a reasonably complete story for threading features: 1) accessing a GSettings instance (or multiple separate instances) from different threads is safe 2) creating/destroying GSettings instances in multiple threads at the same time is safe 3) the 'thread default context' at the time of g_settings_new() is where the signals go this is all GSettings itself. the backends may or may not be threadsafe. "memory" backend is not threadsafe right now for example. i'm aiming for dconf to be. i think there is one operation left that is thread-unsafe: interacting with a GSettings in one thread while calling g_settings_delay() in another. that's a pretty unusual case, though. if you run into bugs/issues with the new (claimed) thread-safety, please file some bugs to let me know on a case-by-case basis.