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

[Maciej Stachowiak]

On Feb 9, 2013, at 10:11 AM, Adam Barth <abarth at webkit.org> wrote:

> On Fri, Feb 8, 2013 at 8:19 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> 
> On Feb 8, 2013, at 2:33 PM, Darin Fisher <darin at chromium.org> wrote:
>> I would recommend minimizing the re-architecture of WebCore as you are in the early stages of upstreaming.  It seems like you already have a working port that you could simply upstream.  You could then work with others in the community to introduce new concepts to WebCore with the full disclosure of code as an aide to the process.  Another option might be to open source the entire thing as a branch somewhere.
> 
>> 
>> After the initial upstreaming or sharing of code is complete, you could then catalog all of the warts.  The fact that isMainThread returns true when called on more than one thread would be one such wart.  I can imagine a meta bug tracking all of these warts.  This would make it a lot easier for others to understand the overall change in direction needed for WebKit to properly support the iOS port.
> 
> That's approximately what we're planning to do. We are upstreaming incrementally, starting with simple pieces, and documenting issues. The bug that sparked this thread was a relatively change to isMainThread(), plus a function rename, and we are no longer asking for the function rename. It will likely be a dozen line patch touching a single mac/ios-specific file.
> 
> We'd really like to fully upstream the simpler components like WTF (where the changes are all simple and targeted) even if we can't as easily do WebCore (where there may be more complex and controversial diffs).
> 
> From what you've said, it sounds like this issue doesn't apply to WebKit2 on iOS. 

(1) What WebKit2 on iOS? We have not announced or shipped such a thing. The code used by MobileSafari, and by third party apps like the embedded browser in Twitter, or Chrome for iOS is a WebKit1 based port.

(2) You might reasonably guess that WebKit2 on iOS is a plausible future direction. If we did do it, then as on Mac we would consider it a requirement for it to use the same binaries for WebCore and lower (though we'd turn off the Web Thread at runtime).

> Perhaps we should focus on merging WebKit2 into trunk and delay having to worry about running WebCore on multiple interlocking threads.

This suggestion is approximately equivalent to "let's not merge yet", for reasons stated above.

There are certainly pros and cons to merging. It would be great get input from the broader WebKit community on the tradeoff of merging sooner vs avoidance of weird legacy code in the main tree. In the meantime, we'll stick to merging things that are not overly controversial as much as we can.

Regards,
Maciej


P.S. "Running WebCore on interlocking threads" is a needlessly scary way to describe what iOS WebKit does. There is no complex fine-grained locking or actual parallel execution. It's more like what would happen if you ran WebKit on a GCD dispatch queue or a thread in a userspace M:N threading library, instead of on an underlying OS-level thread (really it's a restricted subset of that). As such, it has very little impact on WebCore and below. Mainly it just requires that the threading primitives have an appropriate platform implementation on iOS.

For anyone interested in learning more about this, I think Ben had the best high-level explanation: <https://bugs.webkit.org/show_bug.cgi?id=109071#c14>. We can also provide more detail if desired.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130209/1fd0f416/attachment.html>