Bug 65809 – Move the shared LineBreakIteratorPool from ThreadGlobalData into its own ThreadSpecific

• Component: Text
• Status: RESOLVED FIXED

Move the shared LineBreakIteratorPool from ThreadGlobalData into its own ThreadSpecific

<rdar://problem/9338442>

Created attachment 103145 [details]
Remove ThreadGlobalData::lineBreakIteratorPool() and implement LineBreakIteratorPool::shared() using ThreadSpecific

[Darin Adler]

Comment on attachment 103145 [details]
Remove ThreadGlobalData::lineBreakIteratorPool() and implement LineBreakIteratorPool::shared() using ThreadSpecific

View in context: https://bugs.webkit.org/attachment.cgi?id=103145&action=review

> Source/WebCore/platform/text/LineBreakIteratorPoolICU.h:92
> +    static WTF::ThreadSpecific<LineBreakIteratorPool>* staticPool;

Since this is used only in one function it could be a static local to the function rather than a static data member. If it was, the function would not need an explicit check for null and we also would have no need for LineBreakIteratorPoolICU.cpp.

Created attachment 103149 [details]
Remove ThreadGlobalData::lineBreakIteratorPool() and implement LineBreakIteratorPool::shared() using ThreadSpecific

Created attachment 103150 [details]
Remove ThreadGlobalData::lineBreakIteratorPool() and implement LineBreakIteratorPool::shared() using ThreadSpecific

Fixed in <http://trac.webkit.org/r92553>.

[Alexey Proskuryakov]

I know what's bad about this approach (frameworks shouldn't waste thread specific keys). What's good about it?

(In reply to comment #7)
> I know what's bad about this approach (frameworks shouldn't waste thread specific keys). What's good about it?

Making the LineBreakIteratorPool actually thread-specific even in ports that don’t enable HTML5 Worker Threads. In that configuration, ThreadGlobalData is shared between all threads in the process; however, LineBreakIteratorPools still need to be per-thread.