summaryrefslogtreecommitdiffstats
path: root/toolkit/components/osfile/tests/xpcshell/test_osfile_kill.js
blob: e32c37224fa4f5a5a7a2e92b52df42e5b94e2197 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
"use strict";

Components.utils.import("resource://gre/modules/osfile.jsm");

// We want the actual global to get at the internals since Scheduler is not
// exported.
var AsyncFrontGlobal = Components.utils.import(
                         "resource://gre/modules/osfile/osfile_async_front.jsm",
                          null);
var Scheduler = AsyncFrontGlobal.Scheduler;

/**
 * Verify that Scheduler.kill() interacts with other OS.File requests correctly,
 * and that no requests are lost.  This is relevant because on B2G we
 * auto-kill the worker periodically, making it very possible for valid requests
 * to be interleaved with the automatic kill().
 *
 * This test is being created with the fix for Bug 1125989 where `kill` queue
 * management was found to be buggy.  It is a glass-box test that explicitly
 * re-creates the observed failure situation; it is not guaranteed to prevent
 * all future regressions.  The following is a detailed explanation of the test
 * for your benefit if this test ever breaks or you are wondering what was the
 * point of all this.  You might want to skim the code below first.
 *
 * OS.File maintains a `queue` of operations to be performed.  This queue is
 * nominally implemented as a chain of promises.  Every time a new job is
 * OS.File.push()ed, it effectively becomes the new `queue` promise.  (An
 * extra promise is interposed with a rejection handler to avoid the rejection
 * cascading, but that does not matter for our purposes.)
 *
 * The flaw in `kill` was that it would wait for the `queue` to complete before
 * replacing `queue`.  As a result, another OS.File operation could use `push`
 * (by way of OS.File.post()) to also use .then() on the same `queue` promise.
 * Accordingly, assuming that promise was not yet resolved (due to a pending
 * OS.File request), when it was resolved, both the task scheduled in `kill`
 * and in `post` would be triggered.  Both of those tasks would run until
 * encountering a call to worker.post().
 *
 * Re-creating this race is not entirely trivial because of the large number of
 * promises used by the code causing control flow to repeatedly be deferred.  In
 * a slightly simpler world we could run the follwing in the same turn of the
 * event loop and trigger the problem.
 * - any OS.File request
 * - Scheduler.kill()
 * - any OS.File request
 *
 * However, we need the Scheduler.kill task to reach the point where it is
 * waiting on the same `queue` that another task has been scheduled against.
 * Since the `kill` task yields on the `killQueue` promise prior to yielding
 * on `queue`, however, some turns of the event loop are required.  Happily,
 * for us, as discussed above, the problem triggers when we have two promises
 * scheduled on the `queue`, so we can just wait to schedule the second OS.File
 * request on the queue.  (Note that because of the additional then() added to
 * eat rejections, there is an important difference between the value of
 * `queue` and the value returned by the first OS.File request.)
 */
add_task(function* test_kill_race() {
  // Ensure the worker has been created and that SET_DEBUG has taken effect.
  // We have chosen OS.File.exists for our tests because it does not trigger
  // a rejection and we absolutely do not care what the operation is other
  // than it does not invoke a native fast-path.
  yield OS.File.exists('foo.foo');

  do_print('issuing first request');
  let firstRequest = OS.File.exists('foo.bar');
  let secondRequest;
  let secondResolved = false;

  // As noted in our big block comment, we want to wait to schedule the
  // second request so that it races `kill`'s call to `worker.post`.  Having
  // ourselves wait on the same promise, `queue`, and registering ourselves
  // before we issue the kill request means we will get run before the `kill`
  // task resumes and allow us to precisely create the desired race.
  Scheduler.queue.then(function() {
    do_print('issuing second request');
    secondRequest = OS.File.exists('foo.baz');
    secondRequest.then(function() {
      secondResolved = true;
    });
  });

  do_print('issuing kill request');
  let killRequest = Scheduler.kill({ reset: true, shutdown: false });

  // Wait on the killRequest so that we can schedule a new OS.File request
  // after it completes...
  yield killRequest;
  // ...because our ordering guarantee ensures that there is at most one
  // worker (and this usage here should not be vulnerable even with the
  // bug present), so when this completes the secondRequest has either been
  // resolved or lost.
  yield OS.File.exists('foo.goz');

  ok(secondResolved,
     'The second request was resolved so we avoided the bug. Victory!');
});

function run_test() {
  run_next_test();
}