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

[Adam Barth]

On Fri, Feb 8, 2013 at 2:45 PM, David Kilzer <ddkilzer at webkit.org> wrote:
> On Feb 8, 2013, at 1:41 PM, Adam Barth <abarth at webkit.org> wrote:
>> Context: https://bugs.webkit.org/show_bug.cgi?id=109071
>> Adam Barth said:
>>> It's not clear to me that running WebCore on multiple interlocked threads is a good idea.  That
>>> seems like a pretty major change to WebCore's architecture.  Is that something that's up for
>>> discussion?
>>
>> Darin Adler said:
>>> I agree that it’s not something I’d do if I was starting a project now.
>>>
>>> In the iOS context, it’s fantastic for discussion as a possibly multi-year major architecture
>>> change, but if we take a hard line on this, then we won’t have the iOS port in the tree for
>>> years, and I think it would be good if we do. iOS WebKit has worked this way for the entire
>>> history of iPhone, so it’s not a change that can be made easily.
>>
>> Darin Adler also said:
>>> I think where you and I may differ is on whether a good solution to the problem would be
>>> valuable to the WebKit project. Is there some way I convince you of the value of fitting
>>> an important existing port of WebKit into our tree in as clean as possible a way?
>>
>> I don't really know how to respond to this thread.  I feel like I'm
>> being offered the following choice:
>>
>> 1) Give up the ability to have technical input to how WebCore works
>> and simply accept all the design choices made in the iOS fork, whether
>> they be good choices or bad.
>>
>> 2) Keep the iOS port in an Apple-internal fork for a number of years.
>>
>> I feel like I'm being asked to make this choice in the context of a
>> growing trend of unilateral action by Apple in this project.  Given
>> that trend, I don't see how I can choose option (1).
>>
>> As much as I would like the iOS port merged into trunk, I'm not
>> willing to give up having a technical say in the project.  Therefore,
>> reluctantly, I'm forced to choose option (2).
>
> 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?

Adam