Threaded data provider: Support main thread data notifications (Chrome side)

content/child/resource_dispatcher.cc

Index: content/child/resource_dispatcher.cc
diff --git a/content/child/resource_dispatcher.cc b/content/child/resource_dispatcher.cc
index 7cbc7fa53e3249f3e79802d1b407a3cf02f3a70e..3441007b4a9cf909bfc6d12572d7f78cb5fd2e03 100644
--- a/content/child/resource_dispatcher.cc
+++ b/content/child/resource_dispatcher.cc
@@ -578,6 +578,17 @@ void ResourceDispatcher::OnRequestComplete(
 
   base::TimeTicks renderer_completion_time = ToRendererCompletionTime(
       *request_info, request_complete_data.completion_time);
+
+  // If we have a threaded data provider, this message needs to bounce off the
+  // background thread before it's returned to this thread and handled,
+  // to make sure it's processed after all incoming data.
+  if (request_info->threaded_data_provider) {
+    request_info->threaded_data_provider->OnRequestCompleteForegroundThread(
+        weak_factory_.GetWeakPtr(), request_complete_data,
+        renderer_completion_time);
+    return;
+  }
+
   // The request ID will be removed from our pending list in the destructor.
   // Normally, dispatching this message causes the reference-counted request to
   // die immediately.
@@ -589,6 +600,23 @@ void ResourceDispatcher::OnRequestComplete(
                            request_complete_data.encoded_data_length);
 }
 
+void ResourceDispatcher::CompletedRequestAfterBackgroundThreadFlush(

[davidben, 2015/01/23 19:46:43]

Huh. I never failed a separate bug for this, but would this fix the parser half
of this guy too?
https://code.google.com/p/chromium/issues/detail?id=422246#c5

Though it seems weird to me, design-wise, that we're relying on
ThreadedDataProvider being "done" with its processing in one background thread
event loop iteration. (As opposed to the ThreadedDataProvider getting the
completion signal, flushing whatever it needs to flush, and then informing the
WebURLLoaderClient outside ResourceDispatcher.)

[oystein (OOO til 10th of July), 2015/01/23 21:23:47]

Interesting! It actually might, though it depends on what is actually stopping
the parser. If anything triggered by ResourceMsg_RequestComplete, it would.
Well, we can safely rely on it since we can assume that the RequestComplete IPC
will be received on the I/O thread after any of the actual data IPCs, hence this
call (which will bounce from the I/O -> Mainthread -> Parserthread) will be
processed after the data which bounces I/O -> Parserthread directly.

[davidben, 2015/01/26 21:53:12]

Yeah, I think that stop was triggered by ResourceComplete.

+    int request_id,
+    const ResourceMsg_RequestCompleteData& request_complete_data,
+    const base::TimeTicks& renderer_completion_time) {
+  PendingRequestInfo* request_info = GetPendingRequestInfo(request_id);
+  if (!request_info)
+    return;
+
+  RequestPeer* peer = request_info->peer;
+  peer->OnCompletedRequest(request_complete_data.error_code,
+                           request_complete_data.was_ignored_by_handler,
+                           request_complete_data.exists_in_cache,
+                           request_complete_data.security_info,
+                           renderer_completion_time,
+                           request_complete_data.encoded_data_length);
+}
+
 int ResourceDispatcher::AddPendingRequest(RequestPeer* callback,
                                           ResourceType resource_type,
                                           int origin_pid,