[Webkit-unassigned] [Bug 26126] New: Refactor methods of WorkerMessagingProxy used to talk to main-thread loader into new interface.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=26126

           Summary: Refactor methods of WorkerMessagingProxy used to talk to
                    main-thread loader into new interface.
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebCore Misc.
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: dimich at chromium.org
                CC: ap at webkit.org, levin at chromium.org, jianli at chromium.org


This is a part of work to enable implementation of XHR in workers in Chromium,
and can be used by nested workers implementation as well. It introduces
additional WorkerLoaderProxy.

We have WorkerObjectProxy and WorkerContextProxy already, however, Workers not
only talk back and forth with WorkerObject but they also need to talk to the
loading code that normally lives on a main thread. In addition, in
multi-process browsers, the 'loading context' can be a distinct instance from
'Worker object' and can live in different processes. 

WorkerThreadableLoader::MainThreadBridge used to use methods on
WorkerMessagingProxy directly to schedule loading tasks on main thread and get
the results back on worker thread. The new abstract interface
WorkerLoadignProxy gets these methods so WorkerMessagingProxy can implement
them, as well as Chromium, since it doesn't have WorkerMessagingProxy but
rather has a set of IPC proxies on its own.

WorkerThreadableLoader::MainThreadBridge now uses an instance of
WorkerLoaderProxy to talk to the DocumentThreadaableLoader. Some FIXMEs were
removed.

A small note about removing a check for "askedToTerminate" from
WorkerThreadableLoader::MainThreadBridge::mainThreadCreateLoader: David Levin
and I looked at it together and we don't see danger in removing this - so no
need to add this method on new WorkerLoaderProxy. The absence of this check
only avoids creating the main thread loader in some small number of cases cases
when the worker is being terminated from the parent side but the tasks 'crossed
in queues'. The loader will still be destroyed as a result of WorkerContext
destruction, so it seems to be an optimization for a pretty narrow case.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.