Use ThreadSafeSender in a couple of places.

Use ThreadSafeSender in a couple of places.

BUG=174200
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=186298

[michaeln, 2013-02-27 02:31:13]

ptal

[jam, 2013-02-27 02:46:14]

lgtm

https://codereview.chromium.org/12330162/diff/5001/content/common/fileapi/web...
File content/common/fileapi/webblobregistry_impl.cc (right):

https://codereview.chromium.org/12330162/diff/5001/content/common/fileapi/web...
content/common/fileapi/webblobregistry_impl.cc:13: #include
"ipc/ipc_sync_message_filter.h"
why is this needed?

[michaeln, 2013-02-27 20:16:17]

https://codereview.chromium.org/12330162/diff/5001/content/common/fileapi/web...
File content/common/fileapi/webblobregistry_impl.cc (right):

https://codereview.chromium.org/12330162/diff/5001/content/common/fileapi/web...
content/common/fileapi/webblobregistry_impl.cc:13: #include
"ipc/ipc_sync_message_filter.h"
On 2013/02/27 02:46:14, jam wrote:
> why is this needed?

Done, its not.

[michaeln, 2013-02-27 21:29:27]

To get this to play well with RenderViewTests, I had to change a test for
whether ChildThread::current() is valid. The thread getter crashes if there is
!process.

  // ChildProcess and ChildThread may not exist in some tests.
  if (ChildProcess::current())
    thread_safe_sender_ = ChildThread::current()->thread_safe_sender();

[jam, 2013-02-27 21:40:15]

https://codereview.chromium.org/12330162/diff/6009/content/worker/worker_webk...
File content/worker/worker_webkitplatformsupport_impl.cc (right):

https://codereview.chromium.org/12330162/diff/6009/content/worker/worker_webk...
content/worker/worker_webkitplatformsupport_impl.cc:76: if
(ChildProcess::current())
it's confusing to see that ChildProcess needs to be null-checked before
accessing ChildThread::current. can you just make ChildThread::current null
check ChildProcess?

[michaeln, 2013-02-27 22:44:26]

ok

[michaeln, 2013-03-02 01:32:06]

I'm hung up on a failing test with this...
WorkersFileWriterEventsSharedWorker

The entire set of worker filewriter tests  (WorkersFile*) don't run on my local
host with or without my changes. They timeout w/o doing anything, so i'm flying
blind without being able to witness what the heck is happening when this test
runs for real.

[michaeln, 2013-03-02 02:39:22]

I'm less blind than i was an hour ago.

I've got other webkit/webcore changes in my local build that i forgot about,
changes that shine a spotlight on a stupid bug in chromium that explains the
timeouts (see https://codereview.chromium.org/12388058/).

So soon'ish, I'll should have a handle on wassup with
WorkersFileWriterEventsSharedWorker in light of this CL.

[michaeln, 2013-03-05 02:38:14]

> So soon'ish, I'll should have a handle on wassup with
> WorkersFileWriterEventsSharedWorker in light of this CL.

Yup... ChildThread::current() is NULL when WorkerWebKitPlatformSupportImpl is
being constructed since ChildProcess's main thread is set after the WorkerThread
and its aggregates are constructed. Renderer infrastructure is composed
differently such that ChildThread::current() is valid during
RendererWebKitPlatformSupportImpl construction.

Fixed by explicitly passing in the thread_safe_sender to
WorkerWebKitPlatformSupportImpl's constructor instead of fishing it out of
ChildThread::current().

[commit-bot: I haz the power, 2013-03-05 20:54:43]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/michaeln@chromium.org/12330162/31018

[commit-bot: I haz the power, 2013-03-05 21:01:28]

Step "update" is always a major failure.
Look at the try server FAQ for more details.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_clan...

[commit-bot: I haz the power, 2013-03-05 22:18:21]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/michaeln@chromium.org/12330162/67001

[commit-bot: I haz the power, 2013-03-06 00:36:14]

Change committed as 186298