DevTools: introduce WebInspector.Throttler

Source/devtools/front_end/common/Throttler.js

Index: Source/devtools/front_end/common/Throttler.js
diff --git a/Source/devtools/front_end/common/Throttler.js b/Source/devtools/front_end/common/Throttler.js
new file mode 100644
index 0000000000000000000000000000000000000000..fc6803a9538a5a16874bdf1bbb1968c9d9c85ac8
--- /dev/null
+++ b/Source/devtools/front_end/common/Throttler.js
@@ -0,0 +1,70 @@
+// 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.
+
+/**
+ * @constructor
+ * @param {number} timeout
+ */
+WebInspector.Throttler = function(timeout)

[aandrey, 2014/06/10 15:08:38]

IMO, the most common use case in our code is: send a protocol command only after
the previous one is finished. (i.e. when backend takes more time to process a
command than the frontend to generate a new one).

If I understand correctly, this class does not handle that cases (i.e. there
should be no timeouts at all).

Does it make sense to generalize this class even more?

+{
+    this._timeout = timeout;
+    this._isRunningProcess = false;
+    this._processTimeout = null;

[aandrey, 2014/06/10 14:59:53]

remove

+    this._asSoonAsPossible = false;
+    this._process = null;

[aandrey, 2014/06/10 14:59:53]

jsdoc

[lushnikov, 2014/06/10 16:05:09]

Done.

+}
+
+WebInspector.Throttler.prototype = {
+    _processCompleted: function()
+    {
+        this._isRunningProcess = false;
+        if (this._process)
+            this._innerSchedule();
+    },
+
+    _onTimeout: function()
+    {
+        this._processTimeout = null;

[aandrey, 2014/06/10 14:59:53]

delete this._processTimeout;

[lushnikov, 2014/06/10 16:05:09]

Done.

+        this._asSoonAsPossible = false;
+        this._isRunningProcess = true;
+
+        // Process might issue synchronous calls to this throttler.
+        var process = this._process;
+        this._process = null;
+        process(this._processCompleted.bind(this));
+    },
+
+    /**
+     * @param {function(!WebInspector.Throttler.FinishCallback)} process
+     * @param {boolean=} asSoonAsPossible
+     */
+    schedule: function(process, asSoonAsPossible)
+    {
+        // Deliberately skip previous process.
+        this._process = process;

[vsevik, 2014/06/10 11:39:00]

var force = asSoonAsPossible && !this._asSoonAsPossible;

[lushnikov, 2014/06/10 16:05:09]

Done.

+        this._asSoonAsPossible = this._asSoonAsPossible || !!asSoonAsPossible;
+
+        if (this._isRunningProcess)
+            return;
+
+        this._innerSchedule();
+    },
+
+    _innerSchedule: function()
+    {
+        if (this._processTimeout && !this._asSoonAsPossible)

[vsevik, 2014/06/10 11:39:00]

if (this._processTimeout && !force)
    return;

[lushnikov, 2014/06/10 16:05:09]

Done.

+            return;
+        if (this._processTimeout && this._asSoonAsPossible)
+            clearTimeout(this._processTimeout);
+
+        // Pretend the process is running to avoid timer rescheduling.
+        this._isRunningProcess = this._asSoonAsPossible;

[dgozman, 2014/06/09 19:43:11]

If you clear |this._asSoonAsPossible| here:
- no need to fake isRunningProcess;
- call to another schedule before |_onTimeout| will initiate new process, which
should be better.

[lushnikov, 2014/06/10 09:05:22]

1. Consider having for-loop, which does throttler.schedule(process, true). I
would like to avoid repeated setTimeout/clearTimeout in this case. That's the
reason for isRunningProcess faking.

2. I'm not sure I follow here - are we talking about rescheduling timer? If so,
that's not what I want.

+
+        var timeout = this._asSoonAsPossible ? 0 : this._timeout;
+        this._processTimeout = setTimeout(this._onTimeout.bind(this), timeout);
+    }
+}
+
+/** @typedef {function()} */
+WebInspector.Throttler.FinishCallback;