Thanks for the heads up! -Darin
On Sun, Feb 10, 2013 at 1:53 PM, Maciej Stachowiak <m...@apple.com> wrote: > > Here is a list all iOS-specific changes in WebCore and below that are due > to the iOS WebKit threading model, from an exhaustive review of diffs to > the downstream source. I'm not sure anyone needs this to make a decision > any more, but it may be helpful to people to know what's coming as we > merge, and to provide input about specific items if they care to. > > > Key: > - Probably has to be upstreamed for the WebThread to work in the open > source tree > = Probably has to be upstreamed, but only affects files specific to the > iOS port and/or the Mac port > + Can likely be removed before upstreaming > % Can probably be removed sooner than other differences (these things are > needed for a non-WebKit use on the system which is likely to go away) > ? I'm not sure what status this is > > > In WTF: > - Changing WTF::MainThread to recognize either the web thread of the main > thread > - Changes to ThreadRestrictionVerifier to deal with web thread vs main > thread > - Changing the assert in StringStatics.cpp to assert the true main thread, > not isMainThread() (probably not strictly necessary) > - Change the StackBounds consistency check to adapt to main thread vs Web > thread (this is a class used by JSC for conservative stack scanning) > - Sharing of the JSC identifier table (but no locking for that) > % Locking and sharing for AtomicString (possibly removable; was added to > avoid a crash on exit) > > In JSC, one change total: > - A trick to avoid creating the GC timer on the wrong thread > > In WebCore: > - In JSDOMWindowBase.cpp, arrange for JSC to handle the Web thread > correctly > - A change to get ThreadGlobalData to be the same on the web thread and > the main thread > - ScriptDebugServer.cpp, drop and reacquire the web thread lock around a > nested run loop in ScriptDebugServer > - The Web thread messages the main thread about some events via > WKContentObservation > = The actual implementation of the Web Thread and associated locking and > messaging mechanisms > = Not initializing threading in SharedBufferMac.mm +initialize (to avoid > initializing on the wrong thread) > = Not initializing threading in WebScriptObject.mm +initialize (to avoid > initializing on the wrong thread) > = The iOS implementation of SharedTimer operates on the WebThread run loop > and messages the WebThread > = Taking the Web thread lock in an iOS-specific accessibility > implementation file > = Locking around the ObjC DOM wrapper cache > = Schedule CFNetwork callbacks on the Web thread runloop rather than the > main runloop > = The iOS tile cache implementation uses locking and messaging between the > web thread and main thread much like the tile cache in the open source tree > does it between the main thread and the scrolling thread > = CALayer implementations sometimes grab the global lock and/or message to > the WebThread from the main thread (affects WebLayer, PlatformCALayer, and > a special layer that exists for text tracks) > = An iBooks-specific workaround to target the main thread in > LayerFlushSchedulerMac > = Some messaging from the web thread to the main thread due to the weird > way HTML5 video is implemented on iOS, in CA-specific files > = WebCoreMotionManager (a new file that does not exist upstream) uses > WebThread primitives > + Some places that check isMainThread() || pthread_main_np(), which I > expect will not be needed with the isMainThread() change and will likely be > fixed before upstreaming; we're changing isMainThread() specifically to > avoid sprinkling these diffs all over WebCore > + In several places, avoid asserting m_thread == currentThread() (these > diffs can probably be eliminated as by introducing an isCurrentThread() > function) > + An iOS-specific extra ASSERT in ThreadTimers.cpp (probably not needed) > + Apparently obsolete includes of "WebCoreThread.h" in some files (e.g. > TextBreakIteratorICU.cpp) > + Apparently obsolete code to include "WebCoreThreadMessage.h" in some > generated bindings (seems unused) > + Apparently obsolete code to include "WebCoreThreadMessage.h" in some > files (e.g. DOMHTML.mm) > + An iOS-specific DiskImageCache in WebCore/loader uses threading in a > non-portable way - it directly uses libdispatch and messages the WebThread. > We can likely either remove it or rewrite it to do its threading in a more > portable way. > % A mutex in FontCache.cpp around access to the font cache (needed for a > non-WebKit use of WebCore that's likely to be phased out a fair bit sooner > than the Web thread) > ? Make ScriptController::initializeThreading a no-op (no idea why this is > needed) > ? Make HTMLParserScheduler yield if it is at a yield candidate point and > the main thread is waiting on the web thread lock (this was done long ago > for responsiveness, but we need to retest) > ? A mutex to guard creation and pausing of the database thread (I don't > understand why this is needed) > > _______________________________________________ > 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