3 ms·

I don't know much Java. Does 'System.in.read(buffer)' block until stdin is at EOF or buffer is full? Then this solution would be somewhat broken. Imagine a l

I don't know much Java. Does 'System.in.read(buffer)' block until stdin is at EOF or buffer is full? Then this solution would be somewhat broken. Imagine a low-bandwidth source on stdin and a audio player connected to stdout, like wget -O - http://audiostream | java inout.java | mplayer /dev/stdin If I had to write this in C I'd use file descriptors in non-blocking mode and select(). With Tcl one could use event-based IO.

deleted 13y ago
[deleted]
kilburn 13y ago
Using non-blocking mode may be better, but to answer your question: yes, it does block [1]. [1] http://docs.oracle.com/javase/7/docs/api/java/io/InputStream.html#read%28%29 http://docs.oracle.com/javase/7/docs/api/java/io/InputStream...
- Perseids 13y ago
  (You referenced the one byte read function, instead of the multi-byte function used in the OP.) The documentation does not answer how long it blocks. Blocking when there is no input is completely ok in this use case as there is nothing better to do instead of waiting for input. The relevant question is how long it blocks after there is some input available for efficiency reasons.
  - dvdkhlng 13y ago
    > there is nothing better to do instead of waiting for input. In case no more input is available it would be best to already output the data that have accumulated in buffer. Else in case the input program deadlocks you're never going to see the last (up to 8191) bytes output. This is what non-blocking I/O is for. With non-blocking I/O you first wait until your input channel becomes readable, then reading functions return as soon as the data available for read is exhausted.
    - Perseids 13y ago
      You are right but I was talking about the case when no input was there to be read since the call to `read` and also about this specific application: > Blocking when there is no input is completely ok in this use case as there is nothing better to do instead of waiting for input. (Emphasis is new.)
      - dvdkhlng 13y ago
        You're right, I overlooked the reference to the function reading a single byte.
Perseids 13y ago
The documentation [1] does not mention any buffering unfortunately. In a quick test on the console it showed line-buffering behavior, so it probably depends on the input file type? [1] http://docs.oracle.com/javase/7/docs/api/java/io/InputStream.html#read%28byte[]%29 http://docs.oracle.com/javase/7/docs/api/java/io/InputStream...
acqq 13y ago
Not knowing the exact details of used classes, the bigger question is if the exceptions in the OP code can be thrown and if some try catch is needed. In Java the classes like to throw a lot.

deleted 13y ago

[deleted]

kilburn 13y ago

Using non-blocking mode may be better, but to answer your question: yes, it does block [1]. [1] http://docs.oracle.com/javase/7/docs/api/java/io/InputStream.html#read%28%29 http://docs.oracle.com/javase/7/docs/api/java/io/InputStream...

Perseids 13y ago
(You referenced the one byte read function, instead of the multi-byte function used in the OP.) The documentation does not answer how long it blocks. Blocking when there is no input is completely ok in this use case as there is nothing better to do instead of waiting for input. The relevant question is how long it blocks after there is some input available for efficiency reasons.
- dvdkhlng 13y ago
  > there is nothing better to do instead of waiting for input. In case no more input is available it would be best to already output the data that have accumulated in buffer. Else in case the input program deadlocks you're never going to see the last (up to 8191) bytes output. This is what non-blocking I/O is for. With non-blocking I/O you first wait until your input channel becomes readable, then reading functions return as soon as the data available for read is exhausted.
  - Perseids 13y ago
    You are right but I was talking about the case when no input was there to be read since the call to `read` and also about this specific application: > Blocking when there is no input is completely ok in this use case as there is nothing better to do instead of waiting for input. (Emphasis is new.)
    - dvdkhlng 13y ago
      You're right, I overlooked the reference to the function reading a single byte.

Perseids 13y ago

The documentation [1] does not mention any buffering unfortunately. In a quick test on the console it showed line-buffering behavior, so it probably depends on the input file type? [1] http://docs.oracle.com/javase/7/docs/api/java/io/InputStream.html#read%28byte[]%29 http://docs.oracle.com/javase/7/docs/api/java/io/InputStream...

acqq 13y ago

Not knowing the exact details of used classes, the bigger question is if the exceptions in the OP code can be thrown and if some try catch is needed. In Java the classes like to throw a lot.