On Fri, Feb 8, 2013 at 2:45 PM, David Kilzer <ddkil...@webkit.org> wrote: > On Feb 8, 2013, at 1:41 PM, Adam Barth <aba...@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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
