On Fri, Jul 20, 2018 at 11:53:22AM -0400, Ehsan Akhgari wrote:
On Fri, Jul 20, 2018 at 5:00 AM, Jonathan Kew <jfkth...@gmail.com> wrote:
+1 to that. Our need for OMT access to prefs is only likely to grow, IMO,
and we should just fix it once, so that any code (regardless of which
thread(s) it may eventually run on) can trivially read prefs.
Even if that means we can't adopt Robin Hood hashing, I think the
trade-off would be well worthwhile.
While it's true that the need for reading more prefs from workers will
continue to grow, given the number of prefs we have I think it's safe to
say that the set of prefs that we need to access from threads beside the
main thread will be a minority of the entire set of prefs. So one way to
have our cake and eat it too would be to separate out the prefs that are
meant to be accessible through a worker thread and expose them through an
alternate thread-safe API which may be a bit more costly to call on the
main thread, and keep the rest of the min-thread only prefs on the existing
non-thread-safe APIs. This won't be as elegant as having one set of APIs
to work with, of course.
This is what we have atomic var caches are for. They can't currently be used
for string preferences, but that's a problem that could be solved with an
rwlock. They're also a bit difficult to use for preferences which aren't known
at compile time, but we've generally been trying to move away from using the
preference service for such things.
For the sorts of preferences that are generally needed by Worker threads,
though, they should mostly just work as-is.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
