Bug 65809 - Move the shared LineBreakIteratorPool from ThreadGlobalData into its own ThreadSpecific
Summary: Move the shared LineBreakIteratorPool from ThreadGlobalData into its own Thre...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Text (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: mitz
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2011-08-06 00:41 PDT by mitz
Modified: 2011-08-06 19:39 PDT (History)
1 user (show)

See Also:

Attachments
Remove ThreadGlobalData::lineBreakIteratorPool() and implement LineBreakIteratorPool::shared() using ThreadSpecific (12.34 KB, patch)
2011-08-06 00:54 PDT, mitz 		no flags Details | Formatted Diff | Diff
Remove ThreadGlobalData::lineBreakIteratorPool() and implement LineBreakIteratorPool::shared() using ThreadSpecific (3.86 KB, patch)
2011-08-06 09:45 PDT, mitz 		no flags Details | Formatted Diff | Diff
Remove ThreadGlobalData::lineBreakIteratorPool() and implement LineBreakIteratorPool::shared() using ThreadSpecific (4.11 KB, patch)
2011-08-06 09:49 PDT, mitz 		sam: review+
Details | Formatted Diff | Diff
Show Obsolete (2) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description mitz 2011-08-06 00:41:44 PDT 
Move the shared LineBreakIteratorPool from ThreadGlobalData into its own ThreadSpecific
Comment 1 mitz 2011-08-06 00:42:34 PDT 
<rdar://problem/9338442>
Comment 2 mitz 2011-08-06 00:54:21 PDT 
Created attachment 103145 [details]
Remove ThreadGlobalData::lineBreakIteratorPool() and implement LineBreakIteratorPool::shared() using ThreadSpecific
Comment 3 Darin Adler 2011-08-06 07:45:56 PDT 
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.
Comment 4 mitz 2011-08-06 09:45:08 PDT 
Created attachment 103149 [details]
Remove ThreadGlobalData::lineBreakIteratorPool() and implement LineBreakIteratorPool::shared() using ThreadSpecific
Comment 5 mitz 2011-08-06 09:49:59 PDT 
Created attachment 103150 [details]
Remove ThreadGlobalData::lineBreakIteratorPool() and implement LineBreakIteratorPool::shared() using ThreadSpecific
Comment 6 mitz 2011-08-06 10:01:15 PDT 
Fixed in <http://trac.webkit.org/r92553>.
Comment 7 Alexey Proskuryakov 2011-08-06 17:34:48 PDT 
I know what's bad about this approach (frameworks shouldn't waste thread specific keys). What's good about it?
Comment 8 mitz 2011-08-06 19:39:50 PDT 
(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.