| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
R=dglazkov
Review URL: http://codereview.chromium.org/113186
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15739 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
rest of the WebKit API, which is single threaded. Also a bunch of small fixes to make layout tests pass: the dll was being unloaded while its functions were still queued to be dispatched, and a string allocated in the dll was being GC'd in test shell.
BUG=11011
Review URL: http://codereview.chromium.org/102005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15087 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
BUG=10995
R=jam
Review URL: http://codereview.chromium.org/92144
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14461 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
the code path to do static value initializations for worker process.
Review URL: http://codereview.chromium.org/66063
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13615 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
our worker processs, we do not run any WebKit code in main thread. Thus when multiple workers try to start at the same time, we might hit crash due to contention for initializing static values. The fix is to do the initialization first in main thread of worker process.
Review URL: http://codereview.chromium.org/60099
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13125 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The encoding parameter got dropped from Workers (r41871) so
drop it through the whole stack.
The upstream WorkerContextExecutionProxy has trackEvent with a lower
case t, but we pull in the wrong header in some places so make
both headers match.
Review URL: http://codereview.chromium.org/42538
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12326 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/42004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11361 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/40197
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11088 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/39147
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11046 0039d316-1c4b-4281-b951-d872f2087c98
|
|
WebWorkerClient/WebWorker are parallel interfaces of WebCore::{WorkerObjectProxy, WorkerContextProxy} that use Chrome data types. When WebKit requests a WorkerObjectProxy, we create an instance of WebWorkerClientImpl. This class creates an object that implements a Chromium version of WorkerObjectProxy (i.e. with Chrome data types) through WebViewDelegate. That object is a WebWorkerProxy and talks over IPC to a WebWorker object in the worker process. The WebWorker object creates the actual WebCore::Worker object using another class in glue: WebWorkerImpl.
When the WebCore::Worker object running in the worker process wants to talk back to the code running in the renderer, it talks to WebWorkerImpl which implements WebCore::WorkerObjectProxy. WebWorkerImpl converts the data types to Chrome compatible ones, and then calls the WebWorkerClient version which does IPC to get to the renderer process. This ends up at WebWorkerProxy, which calls WebWorkerClientImpl (the original class).
In future changes, sandboxing, multiple worker processes etc will be added. Note that I also had to make two small changes to WebKit, since WorkerMessagingProxy couldn't be created as is for the nested worker case. I'll either check it in myself or work with Jian to do so.
Review URL: http://codereview.chromium.org/27157
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10847 0039d316-1c4b-4281-b951-d872f2087c98
|