[webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[Adam Barth]

On Fri, Feb 8, 2013 at 4:29 PM, Pratik Solanki <psolanki at apple.com> wrote:
> On Feb 8, 2013, at 4:14 PM, Adam Barth <abarth at webkit.org> wrote:
>> On Fri, Feb 8, 2013 at 4:07 PM, David Kilzer <ddkilzer at webkit.org> wrote:
>>> On Feb 8, 2013, at 2:52 PM, Adam Barth <abarth at webkit.org> wrote:
>>>> On Fri, Feb 8, 2013 at 2:45 PM, David Kilzer <ddkilzer at webkit.org> wrote:
>>>>> The iOS port does not require re-architecting WebCore.
>>>>>
>>>>> Bug 109071 was about coming up with a better name for a method that is primarily used in ASSERT()s in WebCore.  Without changing the implementation of that method, debug builds of WebCore on iOS assert instantly since WebCore execution can happen on one of two threads.
>>>>>
>>>>> We can live with keeping the method name as "isMainThread()" and have already moved on to other things.
>>>>>
>>>>> The rest of WebCore is largely unchanged for iOS, other than the usual port-specific code you need for a port, which will be posted for review as we continue to merge.
>>>>
>>>> How do these multiple interlocked threads interact with code that uses
>>>> thread-local storage?
>>>
>>> The UI (main) thread and the web thread share the same thread-local storage.  Those code changes are in 4 or 5 files in WTF.
>>
>> How does that work for code called by WebCore that doesn't use WTF's
>> TLS abstractions?
>
> Can you give an example? I've seen changes in Supplementable.h and WeakPtr.h (in WTF) that assert about the thread id. For those, we're adding PLATFORM(IOS) checks to check for both threads. Are there any others?

One simple example is V8, which stores the current v8::Isolate in
thread-local storage.

However, the problem is certainly not limited to V8, nor is it even
limited to the code we're using today.  Running WebCore on multiple
interlocked threads imposes restrictions on how all the code called by
WebCore use TLS.  Those restrictions might be worthwhile or they might
not be worthwhile.

Before adding these restrictions to WebCore, we should discuss them as
a community and come to consensus about whether their benefits
outweigh their costs.  I don't think it's appropriate for Apple to
impose these restrictions on WebCore unilaterally.

Adam