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

[Adam Barth]

On Fri, Feb 8, 2013 at 4:56 PM, Maciej Stachowiak <mjs 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?
>
> To clarify the overall iOS WebKit threading model:
>
> - Essentially all Web content processing happens on the "Web thread" instead of the main thread. This is approximately isomorphic to how Chromium puts Web content processing in a separate render process, or how WebKit2 puts web content processing into a Web Process.
>
> - Because this work was originally done in a hastier way and with less clear design, it does not do as good a job as Chromium or WebKit2 at sticking strictly to message passing. There are a tiny handful of pieces of WebCore code that get touched directly by the WebKit layer on the main thread. But this is the exception.
>
> We don't have a model where web content processing is broadly spread across multiple thread. We just have a few regrettable (but tricky to fix) exceptions to a message-passing model that processes Web content on a background thread.
>
> I hope this context helps you understand people's answers, and why we believe there is very little impact on WebCore from this change.

Why should the entire WebKit project pay the price for this hasty
design in the iOS fork?

It sounds like this issue is limited to WebKit1.  Perhaps the best
path forward is to upstream the iOS version of WebKit2 and let the
mistakes of WebKit1 on iOS lay fallow.

Adam