Summary: | Use finer grained locking in FontDatabase | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Antti Koivisto <koivisto> | ||||
Component: | Text | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | achristensen, cdumez, commit-queue, ggaren, mmaxfield, webkit-bug-importer | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | WebKit Nightly Build | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Attachments: |
|
Description
Antti Koivisto
2018-10-11 06:26:35 PDT
Created attachment 352038 [details]
patch
Comment on attachment 352038 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=352038&action=review > Source/WebCore/platform/graphics/cocoa/FontCacheCoreText.cpp:-893 > - std::lock_guard<Lock> locker(m_descriptorMapLock); > - > auto folded = familyName.foldCase(); > - return m_familyNameToFontDescriptors.ensure(folded, [&] { Wouldn't moving the lock_guard to after the call to foldCase have the same result? we could leave the call to ensure as it is. > Wouldn't moving the lock_guard to after the call to foldCase have the same
> result? we could leave the call to ensure as it is.
No, the lock needs to be free during the CTFont stuff, that's the slow part (but inherently thread safe).
We lookup the cache with the lock held. If we don't find anything we free the lock and do the CTFont dance. Then we retake the lock to add it to the cache (which might not do anything because other thread might have already added this font).
Comment on attachment 352038 [details] patch Clearing flags on attachment: 352038 Committed r237040: <https://trac.webkit.org/changeset/237040> All reviewed patches have been landed. Closing bug. |