WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
108139
Upstream iOS's AtomicString
https://bugs.webkit.org/show_bug.cgi?id=108139
Summary
Upstream iOS's AtomicString
Benjamin Poulain
Reported
2013-01-28 17:34:17 PST
Some more upstreaming.
Attachments
Patch
(5.68 KB, patch)
2013-01-28 18:12 PST
,
Benjamin Poulain
no flags
Details
Formatted Diff
Diff
Patch
(6.47 KB, patch)
2013-01-29 16:39 PST
,
Benjamin Poulain
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Benjamin Poulain
Comment 1
2013-01-28 18:12:25 PST
Created
attachment 185123
[details]
Patch
Sam Weinig
Comment 2
2013-01-28 19:23:02 PST
Comment on
attachment 185123
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=185123&action=review
> Source/WTF/wtf/text/AtomicString.cpp:34 > +#include <libkern/OSAtomic.h>
Can we use TCSpinLock instead?
> Source/WTF/wtf/text/AtomicString.cpp:44 > +#if PLATFORM(IOS)
I would like this to be a check for something more specific. Maybe USE(WEB_THREAD)
> Source/WTF/wtf/text/AtomicString.cpp:121 > +#if PLATFORM(IOS) > + AtomicStringTableLocker locker; > +#endif
Instead of having all these #ifdefs at the call site, could we just make those without a WebThread have an empty implementation of AtomicStringTableLocker?
Benjamin Poulain
Comment 3
2013-01-28 20:04:38 PST
Comment on
attachment 185123
[details]
Patch
> > Source/WTF/wtf/text/AtomicString.cpp:44 > > +#if PLATFORM(IOS) > > I would like this to be a check for something more specific. Maybe USE(WEB_THREAD)
I like that idea.
> > Source/WTF/wtf/text/AtomicString.cpp:121 > > +#if PLATFORM(IOS) > > + AtomicStringTableLocker locker; > > +#endif > > Instead of having all these #ifdefs at the call site, could we just make those without a WebThread have an empty implementation of AtomicStringTableLocker?
I am afraid someone will misunderstand what it is and use AtomicStringTableLocker at a bad place. With the #ifdef, it is clear you should not touch that if not for iOS.
Adam Barth
Comment 4
2013-01-28 21:25:25 PST
Comment on
attachment 185123
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=185123&action=review
> Source/WTF/ChangeLog:9 > + On iOS, WebCore can be executed from two different threads. To maintain consistency, > + a few changes had been made:
How many changes are required in WebCore to deal with this issue?
Benjamin Poulain
Comment 5
2013-01-28 22:00:58 PST
> > Source/WTF/ChangeLog:9 > > + On iOS, WebCore can be executed from two different threads. To maintain consistency, > > + a few changes had been made: > > How many changes are required in WebCore to deal with this issue?
Not much in common code. It requires quite a bit of code in the iOS platform code. The code does not become multithreaded in any way, the two threads are exclusive. A lot of assertions (ASSERT(isMainThread())) need to be updated but that change is completely transparent if you don't have a WebThread.
Benjamin Poulain
Comment 6
2013-01-29 16:39:09 PST
Created
attachment 185340
[details]
Patch
David Kilzer (:ddkilzer)
Comment 7
2013-01-30 04:38:46 PST
Comment on
attachment 185340
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=185340&action=review
> Source/WTF/wtf/Platform.h:620 > +#define WTF_USE_WEB_THREAD 1
What about USE(IOS_WEB_THREAD) instead?
Benjamin Poulain
Comment 8
2013-02-04 12:48:25 PST
> > Source/WTF/wtf/Platform.h:620 > > +#define WTF_USE_WEB_THREAD 1 > > What about USE(IOS_WEB_THREAD) instead?
I think having IOS in a USE() macro defeats the purpose a bit. But maybe Web_Thread is ambiguous? Maybe?: USE(WEBCORE_WITH_THREADS) USE(THREADED_ACCESSS) USE(MULTITHREAD_WEBKIT) I don't mind in any way. I can update the macro before landing.
David Kilzer (:ddkilzer)
Comment 9
2013-02-04 13:21:18 PST
Comment on
attachment 185340
[details]
Patch r=me
Benjamin Poulain
Comment 10
2013-02-04 14:22:11 PST
Comment on
attachment 185340
[details]
Patch Clearing flags on attachment: 185340 Committed
r141812
: <
http://trac.webkit.org/changeset/141812
>
Benjamin Poulain
Comment 11
2013-02-04 14:22:13 PST
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug