On Tue, Jul 17, 2018 at 02:06:48PM +0100, Jonathan Kew wrote:
On 13/07/2018 21:37, Kris Maglione wrote:
tl;dr: A major change to the architecture preference service has
just landed, so please be on the lookout for regressions.
We've been working for the last few weeks on rearchitecting the
preference service to work better in our current and future
multi-process configurations, and those changes have just landed in
bug 1471025.
Looks like a great step forward!
While we're thinking about the prefs service, is there any possibility
we could enable off-main-thread access to preferences?
I think the chances of that are pretty close to 0, but I'll
defer to Nick.
We definitely can't afford the locking overhead—preference
look-ups already show up in profiles without it. And even the
current limited exception that we grant Stylo while it has the
main thread blocked causes problems (bug 1474789), since it
makes it impossible to update statistics for those reads, or
switch to Robin Hood hashing (which would make our hash tables
much smaller and more efficient, but requires read operations to
be able to move entries).
I am aware that in simple cases, this can be achieved via the
StaticPrefsList; by defining a VARCACHE_PREF there, I can read its
value from other threads. But this doesn't help in my use case, where
I need another thread to be able to query an extensible set of pref
names that are not fully known at compile time.
Currently, it looks like to do this, I'll have to iterate over the
relevant prefs branch(es) ahead of time (on the main thread) and copy
all the entries to some other place that is then available to my
worker threads. For my use case, at least, the other threads only need
read access; modifying prefs could still be limited to the main
thread.
That's probably your best option, yeah. Although I will say that
those kinds of extensible preference sets aren't great for
performance or memory usage, so switching to some other model
might be better.
Possible? Or would the overhead of locking be too crippling?
The latter, I'm afraid.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
