[webkit-dev] A catalog of iOS-specific changes related to the WebThread

[Darin Fisher]

Thanks for the heads up!
-Darin


On Sun, Feb 10, 2013 at 1:53 PM, Maciej Stachowiak <mjs at 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 at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130211/219ed04d/attachment.html>