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

[James Robinson]

On Sat, Feb 9, 2013 at 11:52 AM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> 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.
>

http://trac.webkit.org/changeset/141812 (
https://bugs.webkit.org/show_bug.cgi?id=108139) added fine-grain locking to
the AtomicString table in order to support the iOS WebKit threading model.
 If parallel execution is not possible, why would this need locking?

- James



>
> 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.
>

>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130209/a6aa466e/attachment.html>