Re: Note on PushbackInputStream

[John Keiser]

On 21 Aug 2001 13:47:50 +0200, Dalibor Topic wrote:
> Am Montag, 20. August 2001 17:51 schrieb Tom Tromey:
> I completely understand that. It's a cycle-burner. It's not elegant. It was 
> more of a proof-of-concept that you could fix the bug, without the need for 
> internal threads etc. I have a more elegant solution using wait and notify 
> which is quite close to the solution proposed by John. I wrote a simple test 
> class WaitingPushbackInputsStream which extends PushbackInputStream. It has 
> the following methods:
> 
> public class WaitingPushbackInputStream extends PushbackInputStream {
> [...]
>     public int read() throws IOException {
>       synchronized(this) {
>           synchronized(in) {
>               while(0 == available()) {
>                   try {                       
>                       wait();
>                   }
>                   catch (InterruptedException e) {
>                       // ignore
>                   }
>               }
> 
>               // something is available for reading,
>               // and we've got both locks. this read 
>               // should not block at all.
>               return super.read();
>           }
>       }
>     }
> 
>     public void unread(int oneByte) throws IOException {
>       synchronized(this) {
>           notifyAll();
>           super.unread(oneByte);
>       }
>     }
> }
> 
> this solution avoids polling, and only reads when there is something 
> available for reading. It relies on being notified that there is something 
> available. From what I've seen in my test, it doesn't burn cycles while it's 
> waiting. 
> 
> I used notifyAll(), but in this case where you have a single byte to be 
> (un)read, notify() should be just fine. I think that you need notifyAll() if 
> you push back several bytes, since the notified thread might not want to read 
> all bytes you pushed back. Then you'd be left with some threads waiting 
> although there are bytes available in the pushback buffer.
> 
> The call to available() should take care of someone closing the 
> PushbackInputStream or the sub-stream while a thread is waiting to read.
> 

That's some nice code.  But how could super.unread() ever get called if
read() is in its loop?  They're both synchronized on this.

--John