I have a very simple question.
Based on Java I/O scheme, whenever a thread is waiting for some data, so it will be blocked? is it true? something like this.
byte[] _buff=new byte[1024];
int _r=_in.read(_buff);//it blocks until some data is available
and the just possible way to give up reading is closing the stream by another thread, is it right? something like this.
void run(){
_in.close();
}
so if I am right with above scenarios, so why this is impossible just interrupt a thread which is reading from System.in by closing the stream. I run a thread that just waits for 5 seconds then wants to interrupt/give up rest of the reading from the stream.
void _read_data(){
System.out.print("enter y to save the workspace ");
new Thread(_cancel_thread).start();
int _r=System.in.read();//blocks
}
///////////
void run(){
try{
Thread.sleep(5000);
System.in.close();//doesn't work.
}catch(Exception _ex){}
}
Questions:
1.How to close the stream?! why the closing stream thread cannot close the stream?!
2.Once the stream got closed, how to open it again?!
For the first question, I think this is because maybe(I don't know, not sure) the stream is kinda locked by lower-level, so while it's locked, another thread is just waiting to acquire the lock and close it.
and for second one, I really don't know is there any class(stream) which works with keyboard stream or not, but why do you really want to close it? just keep the stream somewhere (like in=System.in), then redirect the standard stream to another stream by calling System.setIn(newStream), then whenever you want to give keyboard stream back, reset the stream with the reference.
Closing the default system input stream is not good idea, I suggest you utilize either JConsol or jNativeHook, these guys do not block, instead they listen for events.
Related
System.in is the "standard" input stream which supplies user input data. Once closed, this stream can not be re-opened. One such example is in the case of using a scanner to read the user input as follows:
public class Test {
public static void main(String[] args) {
boolean finished;
do {
Scanner inputScanner = new Scanner(System.in);
finished = inputScanner.hasNext("exit");
boolean validNumber = inputScanner.hasNextDouble();
if (validNumber) {
double number = inputScanner.nextDouble();
System.out.print(number);
} else if (!finished) {
System.out.println("Please try again.");
}
inputScanner.close();
} while (!finished);
}
}
In this example, an instance of type Scanner is created and used to read a series of numbers from the user (please ignore other details with this code which go beyond the scope of this example, I know the scanner should be created and closed outside the loop). After a number is retrieved from user input, the instance of this Scanner (i.e., the input stream) is closed. However, when another number is requested from user, and new instance is created, the input stream cannot be opened again. In case of this example, it creates a infinite loop.
The question is: why is not possible to reopen a closed stream?
why is not possible to reopen a closed stream in Java?
That's simply the nature of the underlying operating system constructs that Java streams represent. A stream is essentially a data conduit. Once you close it, it no longer exists. You may be able to create a new one between the same endpoints, but that yields a fundamentally different stream. We could go into implementation considerations such as buffering and stream positioning, but those are really side issues.
You also asked specifically about the standard streams. These are some of the cases that you cannot recreate. The operating system provides each process with its set of standard streams. Once they are closed, there is no way to obtain equivalents. You can put different streams in their place, but you cannot connect them to the original endpoints.
When you close the standard input stream:
If your input was being provided by a pipe, the other end of the pipe is notified. It will close its end and stop sending data. There is no way to tell it you made a mistake and it should start sending again;
If your input was being provided by a file, the OS drops its reference to the file and completely forgets that you were using it. There is just no way provided for you to reopen standard input and continue reading;
If your input was being provided by the console, it works with a pipe. The console is notified, will close its end of the pipe and stop sending you data.
So there's no way to reopen standard input.
BUT... there is also no reason to close standard input, so just don't do that!
A good pattern to follow is:
The code or class that opens a file is responsible for closing it.
If you pass an InputStream to another method that reads from it, that method should not close it. Leave that to the code that opened it. It's like the streams owner.
Similarly, if you pass an OutputStream to another method that writes to it, that method should not close it. Leave that to the code that owns it. BUT if you wrap the stream in other classes that may buffer some data do call .flush() on them to make sure everything comes out!
If you're writing your own wrapper classes around InputStream and OutputStream, don't close the delegate stream in your finalizer. If a stream needs to be cleaned up during GC, it should handle that itself.
In your example code, just don't close that Scanner. You didn't open standard input, so you shouldn't need to close it.
Because Streams are unbounded. You peek values from streams as you need. Then when done simply close it. Streams does not hold it's all data in memory. Streams are designed to process relatively big amount of data which can't be held in memory. So you can't reopen an stream simply because you already have made a loop over it and exhausted all the data. As stream does not hold those data in memory. They are simply lost and that's why you can't reopen it. The better is you create a new stream than reopen an existing one.
Java standard library has chosen a "standardized" approach to InputStream. Even if you may legitimately perceive some streams, such as data incoming from the input console, as logically re-openable, the InputStream represents a generic approach, as it is intended to cover all the possible InputStreams, which many of them are by their nature not re-openable. As described perfectly in #JohnBollinger's answer.
Is it possible to make an InputStream that is identical to a base InputStream, except that when the base stream is blocked, bytes can be inserted into the stream by calling a method? Sketch:
public class HackInputStream extends InputStream {
public HackInputStream (InputStream base) { /* stuff */ }
public int read() throws IOException { /* stuff */ }
public void insertByte(byte b) { /* stuff */ }
}
I will only be inserting bytes when the base stream is definitely blocked, so race conditions shouldn't be an issue. I tried to implement this class using one thread that read bytes greedily from the base stream into a LinkedBlockingQueue. insertByte inserted the byte directly into the queue, and read simply read bytes from the queue, blocking when the queue was empty.
This almost worked... but when I made a Scanner using new Scanner(new HackInputStream(System.in), the nextLine method didn't work. Unfortunately, the reason I wanted this weird class in the first place was to unblock a blocked Scanner!
(Here's the problem I'm trying to solve, in case someone has a better solution:
My program is a "shell" that launches tasks (threads) when given commands. Some of these tasks terminate on their own, and some do not. I want to return immediately to the command prompt when the task terminates, but in case the task never terminates, I want to terminate it by entering a newline.
Currently, the main thread waits for the task to terminate, while a watchdog threads waits for a newline, terminating the task if it receives one. Right now, if the task terminates on its own, I can't enter a command without manually entering a newline. The watchdog thread is uninterruptibly blocked, and it will consume the next line of input no matter what, possibly causing the next command to go unread. I'm trying to change System.in so that I can feed it newlines programmatically.)
Update: I solved my problem in a much simpler way by only calling Scanner.nextLine() if the task was still running.
Is there an elegant way to fire an event when characters are available from System.in? I'd like to avoid polling InputStream.available().
You would have to create a separate thread that blocks in read until something is available.
If you don't want to actually eat up the input, you would have to wrap it with an internal buffer, read into the buffer, shout, and when asked for the input, give back data from the buffer.
You could solve it like this:
InputStream stdin = System.in;
// Create a wrapper (with it's own dedicated read-thread)
MyListenableInputStream listenableInputStream =
new MyListenableInputStream(stdin);
// Update System.in with something more useful.
System.setIn(listenableInputStream);
Sure...start a thread that blocks on the input and then calls your event method when it gets something.
Very generally speaking:
If you already have an event reactor running, create a thread and have it block on read(). When there's data available, have that thread enqueue an event for the reactor to process. If you can't do this, most event reactors provide an InvokeLater, or CallLater method, for you to run some code in the event processing thread.
After notifying or scheduling a function call, go back to blocking on read().
If you want something elegant you could easily implement an ObservableInputStream which accepts a Listener that gets warned about availability of data but you will have to implement it with an inner thread that periodically checks for data and call the listener in case.
Think about the fact that streams aren't supposed to be used as object that send small packets but a continuous stream of bytes, that's why this approach would work only if the data that is given to the input stream doesn't effectively arrives too often (otherwise it would keep calling the listener ad libitum). In addition you will have to care about consistency, if data arrive when something is already available and the listener is warned then something can take all the bytes (which you should place in a temporary buffer) but if there's more data that just arrived you should decide how to handle (give it together with buffer, place in buffer and call listener again, etc)
new Thread(){
public void run() {
while(System.in.get()){
}
}.start();
Im trying to run a thread that goes to a socket, grabs the input stream, and reads it. Im creating hundreds of these threads and have set the timeout for reading and yet the thread still stays at the read() line.
public void readPack() {
socket.setSoTimeout(4*1000);
if (socket.isConnected()) {
buffer parse = new buffer();
parse.addByte((byte) skt.getInputStream().read());
parseIncoming(parse);
}
} catch (Exception e) {}
}
Strange code. You create a buffer, read one byte into it, then parse that byte, then repeat the whole process. One byte surely doesn't take much parsing. You are never checking for -1 from the read so this loop will spin endlessly when the peer disconnects. And finally Socket.isConnected() isn't a useful test, and specifically it doesn't detect the peer disconnecting.
Call skt.available(), and then call read that many times, or use skt.read(byte[]). Other wise skt.read() will block. The timeout your setting is to connect to the socket, and not a read timeout.
i want to read from input stream when i connect to a server socket.
but there may exist some delays between messages how can i read from input stream without busy loop ?
string mes = socketReader.readLine();
above line returns null when no input provided in socket input stream.
i want to be notified somehow when a message is ready in input stream.
tnx
Have you looked asynchronous IO?
In a GUI context, SwingWorker may help: let doInBackground() do the reading, use process() for interim reuslts, and done() to wrap up. You can register a PropertyChangeListener to drive a progress indicator. This article expands on the idea, and a back port to Java 1.5 is available. Here's a simple example that reads from a JDBC source instead of a stream, but the idea is the same.