[Cronet] Initial implementation of HttpURLConnection

components/cronet/android/java/src/org/chromium/net/urlconnection/MessageLoop.java

+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+package org.chromium.net.urlconnection;
+
+import java.util.concurrent.BlockingQueue;
+import java.util.concurrent.LinkedBlockingQueue;
+
+/**
+ * A package protected MessageLoop class for use in
+ * {@link CronetHttpURLConnection}
+ */
+final class MessageLoop {
+    private final BlockingQueue<Runnable> mQueue;
+    // A reusable runnable to quit the message loop.
+    private final Runnable mQuitTask;
+    // Indicates whether this message loop is currently running.
+    private boolean mLoopRunning;
+
+    public MessageLoop() {
+        mQueue = new LinkedBlockingQueue<Runnable>();
+        mQuitTask = new Runnable() {
+            @Override
+            public void run() {
+                mLoopRunning = false;
+            }
+        };
+    }
+
+    /**
+     * Runs the message loop. Be sure to call {@link MessageLoop#postQuitTask()}
+     * to end the loop.
+     */
+    public void loop() {
+        if (mLoopRunning) {
+            throw new IllegalStateException(
+                    "Cannot run loop when it is already running.");
+        }
+        mLoopRunning = true;
+        while (mLoopRunning) {
+            try {
+                Runnable task = mQueue.take(); // Blocks if the queue is empty.
+                task.run();
+            } catch (InterruptedException e) {
+                throw new RuntimeException(e);

[xunjieli, 2014/11/26 16:11:56]

I am not sure what I should do to handle InterruptedException. It is a checked
exception, so I can't rethrow it as a runtime exception. Method signatures of
HttpURLConnection do not have throw causes. Thoughts?

[mef, 2014/11/26 16:36:04]

It sounds like you can get that exception when you are waiting for the task, so
maybe it should quit the loop?

[mmenke, 2014/11/26 17:09:12]

Yes, it should quit the loop (Which re-throwing the error implicitly does,
actually).  The question is how we should surface it to the embedder:  As an
exception (And if so, should it be recoverable) or as a failed error.

If we treat it as a recoverable exception, the mLoopRunning logic may present a
problem - it's now true, so we'd have to set it to false...but we could
theoretically have just posted a quit task when we get the exception, which
would cause yet more problems...

I suggest just treating it as an error and failure the request, for now.

One way to do that:  Don't catch the error here, just make loop throw
InterruptedException.  Catch it in the calling class, and treat it as a failure.
 You'll have to wrap loop calls in another method, but don't think that's a big
deal.

Open to other ideas.

[xunjieli, 2014/11/26 18:37:14]

Done.

+            }
+        }
+    }
+
+    /**
+     * Posts a reusable runnable, {@link #mQuitTask} to quit the loop. This
+     * causes the {@link #loop()} to terminate after processing all currently
+     * enqueued messages.
+     */
+    public void postQuitTask() {
+        try {
+            mQueue.put(mQuitTask);
+        } catch (InterruptedException e) {
+            throw new RuntimeException(e);
+        }
+    }
+
+    /**
+     * Posts a task to the message loop.
+     */
+    public void postTask(Runnable task) {
+        if (task == null) {
+            throw new IllegalArgumentException();
+        }
+        try {
+            mQueue.put(task);
+        } catch (InterruptedException e) {
+            throw new RuntimeException(e);
+        }
+    }
+}