Summary: | Make Settings generated from Settings.yaml work with Workers | ||
---|---|---|---|
Product: | WebKit | Reporter: | Sam Weinig <sam> |
Component: | WebCore Misc. | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED CONFIGURATION CHANGED | ||
Severity: | Normal | CC: | achristensen, beidson, cdumez, darin, ggaren, webkit-bug-importer |
Priority: | P2 | Keywords: | InRadar |
Version: | WebKit Nightly Build | ||
Hardware: | Unspecified | ||
OS: | Unspecified |
Description
Sam Weinig
2020-09-15 15:22:57 PDT
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. With SettingValues, this is now complete. |