* process it; all should produce the same answer, the only difference should be the number of
   * process()/processRemaining() invocations, due to alignment.
   */
  @AndroidIncompatible // slow. TODO(cpovirk): Maybe just reduce iterations under Android.
  public void testExhaustive() throws Exception {
    Random random = new Random(0); // will iteratively make more debuggable, each time it breaks

         * problems can exist with methods like FutureTask.done(), not to mention slow calls to
         * Thread.interrupt() (as discussed in InterruptibleTask). At the end of the day, it's
         * unlikely that cancel() will be slow, so we can probably get away with calling it while
         * holding a lock. Still, it would be nice to avoid somehow.
         */

      )

    client =
      clientTestRule
        .newClientBuilder()
        .eventListenerFactory(clientTestRule.wrap(eventRecorder))
        .connectTimeout(60, TimeUnit.SECONDS) // Deliberately exacerbate slow fallbacks.
        .dns { dnsResults }
        .fastFallback(true)
        .build()
    url =
      serverIpv4
        .url("/")
        .newBuilder()
        .host("localhost")
        .build()

	// WorkerMinLimit min number of workers per node for "slow" mode
	WorkerMinLimit = 50

	// WorkerAutoDefault is default number of workers for "auto" mode
	WorkerAutoDefault = 100

	// MRFWorkerMaxLimit max number of mrf workers per node for "fast" mode
	MRFWorkerMaxLimit = 8

	// MRFWorkerMinLimit min number of mrf workers per node for "slow" mode
	MRFWorkerMinLimit = 2

    assertTrue(enormous instanceof RegularContiguousSet);
    // We can't use reserializeAndAssert because it calls hashCode, which is enormously slow.
    ContiguousSet<Integer> enormousReserialized = reserialize(enormous);
    assertEquals(enormous, enormousReserialized);
  }

  private static final DiscreteDomain<Integer> UNBOUNDED_THROWING_DOMAIN =

    try {
      // if waiting works, this should get stuck
      Queues.drain(q, new ArrayList<>(), 1, MAX_VALUE, NANOSECONDS);
      fail();
    } catch (InterruptedException expected) {
      // we indeed waited; a slow thread had enough time to interrupt us
    }
  }

  // same as above; uninterruptible version
  @SuppressWarnings("ThreadPriorityCheck") // TODO: b/175898629 - Consider onSpinWait.

    // transmitted until the flow-control window is updated from the first request.
    val call2 = client.newCall(Request(server.url("/")))
    val response2 = call2.execute()
    assertThat(response2.code).isEqualTo(200)

    // Close the response body. This should discard the buffered data and update the connection
    // flow-control window.
    response1.close()

         * problems can exist with methods like FutureTask.done(), not to mention slow calls to
         * Thread.interrupt() (as discussed in InterruptibleTask). At the end of the day, it's
         * unlikely that cancel() will be slow, so we can probably get away with calling it while
         * holding a lock. Still, it would be nice to avoid somehow.
         */

   *       </ol>
   *       Given all these possibilities, it is frequently possible for listeners to execute in UI
   *       threads, RPC network threads, or other latency-sensitive threads. In those cases, slow
   *       listeners can harm responsiveness, slow the system as a whole, or worse. (See also the
   *       note about locking below.)
   *   <li>If many tasks will be triggered by the same event, one heavyweight task may delay other

    assertThrows(
        UnsupportedOperationException.class,
        () -> rangeSet.removeAll(ImmutableRangeSet.of(Range.closed(6, 8))));
  }

  @AndroidIncompatible // slow
  public void testExhaustive() {
    ImmutableSet<Range<Integer>> ranges =
        ImmutableSet.of(
            Range.<Integer>all(),
            Range.<Integer>closedOpen(3, 5),
            Range.singleton(1),