On Feb 8, 2013, at 4:14 PM, Adam Barth <aba...@webkit.org> wrote: > On Fri, Feb 8, 2013 at 4:07 PM, David Kilzer <ddkil...@webkit.org> wrote: >> On Feb 8, 2013, at 2:52 PM, Adam Barth <aba...@webkit.org> wrote: >>> On Fri, Feb 8, 2013 at 2:45 PM, David Kilzer <ddkil...@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?
Hi Adam, 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. Regards, Maciej _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
