The biggest hurdle to deal with for moving off of RuntimeEnabledFeatures is making the settings generated from Settings.yaml work with Workers. Specifically, making it so that IDL interfaces exposed to workers can use the EnabledBySetting=Foo syntax to indicate that an interface/operation/attribute is conditionally available based on Settings. (Currently, interfaces/operations/attribute that need this use EnabledAtRuntime, which uses RuntimeEnabledFeatures in a thread unsafe way). I am not sure what the best way to go about this would be. Regardless of the technique we end up going, the end goal for the bindings will probably look pretty much the same. We will go from checks that look like: downcast<Document>(jsCast<JSDOMGlobalObject*>(globalObject)->scriptExecutionContext())->settings()->isFooEnabled() to: jsCast<JSDOMGlobalObject*>(globalObject)->scriptExecutionContext()->settings()->isFooEnabled(); What exactly ScriptExecutionContext::settings() returns, and how it is populated is what we need to figure out.
The most straightforward approach would be to move the 'const Ref<Settings>' member from Document to ScriptExecutionContext, and adding a lock around all getting/setting. (I don't think the overhead of the lock should matter, hopefully nothing is checking a setting in any perf sensitive code, but any settings returning Strings will also have to be switched to always copy the string in and out, so it's not so great). An alternative strategy would be taking a copy of the Settings (or perhaps the subset needed by Workers) when spawning a Worker, and then serializing mutations to the Settings to each currently active Worker as necessary,
cc'ing folks who might have interest in the topic to see if they have opinions.
Would it be possible to make the settings object use std::atomic so we don't need any locks? Most of them would be std::atomic<bool> and we could figure out something for those that aren't.
(In reply to Alex Christensen from comment #3) > Would it be possible to make the settings object use std::atomic so we don't > need any locks? Most of them would be std::atomic<bool> and we could figure > out something for those that aren't. Yeah, we could do that for the bool / integer ones.
<rdar://problem/69396170>
With SettingValues, this is now complete.