import static com.google.common.util.concurrent.NullnessCasts.uncheckedCastNullableTToT;

import org.checkerframework.checker.nullness.qual.Nullable;

/** Emulation for InterruptibleTask in GWT. */
@ElementTypesAreNonnullByDefault
abstract class InterruptibleTask<T extends @Nullable Object> implements Runnable {

  @Override
  public void run() {
    T result = null;
    Throwable error = null;
    if (isDone()) {
      return;

   * identify deadlocks.
   */
  @VisibleForTesting
  static final class Blocker extends AbstractOwnableSynchronizer implements Runnable {
    private final InterruptibleTask<?> task;

    private Blocker(InterruptibleTask<?> task) {
      this.task = task;
    }

    @Override
    public void run() {}

    private void setOwner(Thread thread) {
      super.setExclusiveOwnerThread(thread);

   * identify deadlocks.
   */
  @VisibleForTesting
  static final class Blocker extends AbstractOwnableSynchronizer implements Runnable {
    private final InterruptibleTask<?> task;

    private Blocker(InterruptibleTask<?> task) {
      this.task = task;
    }

    @Override
    public void run() {}

    private void setOwner(Thread thread) {
      super.setExclusiveOwnerThread(thread);

   * that the test isn't exposing a real problem with InterruptibleTask, one that could matter in
   * prod.
   */
  @AndroidIncompatible
  public void testInterruptIsSlow() throws Exception {
    final CountDownLatch isInterruptibleRegistered = new CountDownLatch(1);
    final SlowChannel slowChannel = new SlowChannel();
    final InterruptibleTask<@Nullable Void> task =
        new InterruptibleTask<@Nullable Void>() {
          @Override

         * 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.
         */