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 [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
