2

If I start reading from System.in, it will block the thread until it gets data. There is no way to stop it. Here are all the ways that I've tried:

  • Interrupting the thread
  • Stopping the thread
  • Closing System.in
  • Calling System.exit(0) does indeed stop the thread, but it also kills my application so not ideal.
  • Entering a char into the console makes the method return, but I can't rely on user input.

Sample code that does not work:

public static void main(String[] args) throws InterruptedException {
    Thread th = new Thread(() -> {
        try {
            System.in.read();
        } catch (IOException e) {
            e.printStackTrace();
        }
    });
    th.start();
    Thread.sleep(1000);
    System.in.close();
    Thread.sleep(1000);
    th.interrupt();
    Thread.sleep(1000);
    th.stop();
    Thread.sleep(1000);
    System.out.println(th.isAlive()); // Outputs true
}

When I run this code, it will output true and run forever.

How do I read from System.in in an interruptible way?

piegames
  • 673
  • 10
  • 26
  • System.in.close() – JB Nizet Mar 27 '18 at 19:05
  • @JBNizet do you really think I haven't tried this? – piegames Mar 27 '18 at 19:06
  • it would be `th.close();` no? – Tyler Dickson Mar 27 '18 at 19:07
  • @piegames yes, I do think so. Have you? What's the result? – JB Nizet Mar 27 '18 at 19:08
  • Didn't work, sadly. – piegames Mar 27 '18 at 19:10
  • The correct way to wait for a thread to finish is via join() and not Thread.sleep(). Also calling th.stop() is deprecated and inherently unsafe. – Ayman Mar 27 '18 at 19:10
  • It does here. Edit your question, post the code you tried, and the output you got. – JB Nizet Mar 27 '18 at 19:11
  • I guess you have tried that, but otherwise the correct method would be to use th.interrupt(). That should interrupt the IO operation and ideally the Scanner should not catch the exception and the thread should die. If it doesn't work, try closing the scanner, but I'm skeptical about that. – ewramner Mar 27 '18 at 19:13
  • Strongly related: [How to interrupt java.util.Scanner nextLine call](https://stackoverflow.com/questions/4983065/how-to-interrupt-java-util-scanner-nextline-call). – rgettman Mar 27 '18 at 19:18
  • Hah. Closing the stream works fine in the IDE (probably because it sets System.in to something else than the default System.in, but it indeed doesn't work in the terminal. – JB Nizet Mar 27 '18 at 19:23
  • @rgettman I edited the question so that it shouldn't be a duplicate anymore. – piegames Mar 27 '18 at 19:25
  • There is no guarantee about whether InputStream operations are interruptible. However, Channels do provide such a guarantee, so [wrapping your InputStream](https://docs.oracle.com/javase/9/docs/api/java/nio/channels/Channels.html#newChannel-java.io.InputStream-) may be sufficient. – VGR Mar 27 '18 at 19:53
  • [Java: how to abort a thread reading from System.in](https://stackoverflow.com/questions/6008177/java-how-to-abort-a-thread-reading-from-system-in) looks like a dup, but doesn't provide a good answer. – teppic Mar 28 '18 at 07:57

2 Answers2

3

You should design the run method so that it can determine for itself when to terminate. Calling stop() or similar methods upon the thread would be inherently unsafe.

However, there still remains the question of how to avoid blocking inside System.in.read? To do that you could poll System.in.available until it returns > 0 prior to reading.

Example code:

    Thread th = new Thread(() -> {
        try {
            while(System.in.available() < 1) {
                Thread.sleep(200);
            }
            System.in.read();
        } catch (InterruptedException e) {
            // sleep interrupted
        } catch (IOException e) {
            e.printStackTrace();
        }
    });

Of course, it is generally considered favorable to use a blocking IO method rather than polling. But polling does have its uses; in your situation, it allows this thread to exit cleanly.

A Better Approach:

A better approach that avoids polling would be to restructure the code so that any Thread you intend to kill is not allowed direct access to System.in. This is because System.in is an InputStream that should not be closed. Instead the main thread or another dedicated thread will read from System.in (blocking) then write any contents into a buffer. That buffer, in turn, would be monitored by the Thread you intend to kill.

Example code:

public static void main(String[] args) throws InterruptedException, IOException {
    PipedOutputStream stagingPipe = new PipedOutputStream();
    PipedInputStream releasingPipe = new PipedInputStream(stagingPipe);
    Thread stagingThread = new Thread(() -> {
        try {
            while(true) {
                stagingPipe.write(System.in.read());
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    });     
    stagingThread.setDaemon(true);
    stagingThread.start();
    Thread th = new Thread(() -> {
        try {
            releasingPipe.read();
        } catch (InterruptedIOException e) {
            // read interrupted
        } catch (IOException e) {
            e.printStackTrace();
        }
    });
    th.start();
    Thread.sleep(1000);
    Thread.sleep(1000);
    th.interrupt();
    Thread.sleep(1000);
    Thread.sleep(1000);
    System.out.println(th.isAlive()); // Outputs false
}       
Patrick Parker
  • 4,381
  • 3
  • 15
  • 43
  • I am trying to make a wrapper InputStream using the System.in.available(), but it doesn't seem to work with the Scanner. – piegames Mar 28 '18 at 15:29
  • Make the thread a daemon instead of killing the application with `System.exit()`, it should work the same – piegames Mar 29 '18 at 22:41
  • 1
    PipedInputStream is implemeted with polling. They use wait(1000) loops. I don't know why, just checked the JDK 1.8 source. – Mostowski Collapse Jan 03 '20 at 16:55
  • 1
    @MostowskiCollapse it seems you are correct. Another Java API fail! Developers must make their own FastPipedInputStream subclass. https://stackoverflow.com/questions/28617175/did-i-find-a-bug-in-java-io-pipedinputstream – Patrick Parker Jan 04 '20 at 00:10
0

I've written a wrapper InputStream class that allows to be interrupted:

package de.piegames.voicepi.stt;
import java.io.IOException;
import java.io.InputStream;

public class InterruptibleInputStream extends InputStream {

    protected final InputStream in;

    public InterruptibleInputStream(InputStream in) {
        this.in = in;
    }

    /**
     * This will read one byte, blocking if needed. If the thread is interrupted while reading, it will stop and throw
     * an {@link IOException}.
     */     
    @Override
    public int read() throws IOException {
        while (!Thread.interrupted())
            if (in.available() > 0)
                return in.read();
            else
                Thread.yield();
        throw new IOException("Thread interrupted while reading");
    }

    /**
     * This will read multiple bytes into a buffer. While reading the first byte it will block and wait in an
     * interruptable way until one is available. For the remaining bytes, it will stop reading when none are available
     * anymore. If the thread is interrupted, it will return -1.
     */
    @Override
    public int read(byte b[], int off, int len) throws IOException {
        if (b == null) {
            throw new NullPointerException();
        } else if (off < 0 || len < 0 || len > b.length - off) {
            throw new IndexOutOfBoundsException();
        } else if (len == 0) {
            return 0;
        }
        int c = -1;
        while (!Thread.interrupted())
            if (in.available() > 0) {
                c = in.read();
                break;
            } else
                Thread.yield();
        if (c == -1) {
            return -1;
        }
        b[off] = (byte) c;

        int i = 1;
        try {
            for (; i < len; i++) {
                c = -1;
                if (in.available() > 0)
                    c = in.read();
                if (c == -1) {
                    break;
                }
                b[off + i] = (byte) c;
            }
        } catch (IOException ee) {
        }
        return i;
    }

    @Override
    public int available() throws IOException {
        return in.available();
    }

    @Override
    public void close() throws IOException {
        in.close();
    }

    @Override
    public synchronized void mark(int readlimit) {
        in.mark(readlimit);
    }

    @Override
    public synchronized void reset() throws IOException {
        in.reset();
    }

    @Override
    public boolean markSupported() {
        return in.markSupported();
    }
}

Adjust the Thread.yield() to sleep as long as the maximum latency you can accept and prepare for some exceptions when interrupting, but apart from that it should work fine.

teppic
  • 6,312
  • 1
  • 26
  • 32
piegames
  • 673
  • 10
  • 26
  • Good answer, but you shouldn't swallow the `IOException` in `read(byte b[], int off, int len)`. – teppic Mar 29 '18 at 01:55
  • This may spin on EOF. The contract for `available()` specified in `InputStream` is `0 when it reaches the end of the input stream`. – teppic Mar 29 '18 at 02:22
  • The swallowed exception code is copied from `InputStream.read()` and is intentional. But the `available()` is indeed a problem, thanks for noticing. – piegames Mar 29 '18 at 10:53
  • @teppic nice catch. but there's no way of detecting the EOF prior to read, am I right? this appears to be another Java API fail. – Patrick Parker Mar 29 '18 at 12:54