On Sat, Feb 9, 2013 at 11:52 AM, Maciej Stachowiak <m...@apple.com> wrote:
> > On Feb 9, 2013, at 10:11 AM, Adam Barth <aba...@webkit.org> wrote: > > On Fri, Feb 8, 2013 at 8:19 PM, Maciej Stachowiak <m...@apple.com> wrote: > >> >> On Feb 8, 2013, at 2:33 PM, Darin Fisher <da...@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@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
