🚀 go-pugleaf

On Wed, 14 Jun 2000 14:43:41 +0200, Jeroen Zwartepoorte wrote:

> > You do not show the code that points System.in to your
> > input stream object or the code creates the buffered
> > reader.  My guess is that your problem is with this code.
> 
> That code is very simple:
> 
>     System.setOut(new Pl0PrintStream(textArea));
>     System.setIn(new Pl0InputStream(textArea));
> 
> BufferedReader creation is also trivial:
> 
>     String sTest = new BufferedReader(new
> InputStreamReader(System.in)).readLine();

That looks right.  This may seem obvious, but are you sure that 
readLine() is being executed after the System.setIn()?  You can be sure 
by adding the line:
    System.out.println( System.in );
just before the readLine.

> > You synchronize the code that adds a character to your buffer,
> > but not the code that removes a character from the buffer.
> > I don't believe this will help if you do not do it in both
> > places.
> 
> Why not? If i make sure that when i add something to the Queue,
> i'm the only thread currently accessing that Object, then there
> is no reason to add another synchronized in the read() method?!

But that's not how synchronization works.  When you add something to the 
queue, you grab the lock for your object, which ensures that no other 
thread can grab that lock.  But it does not prevent other threads from 
accessing the object.

The way that you ensure that other threads will not access the object is 
to have all code that accesses the object synchronize with the object's 
lock.  But normally, you do not need to prevent any access, so you may 
only need to synchronize some parts of the code.

> I haven't read the document (yet), but the jdk docs state
> that read() should block until there is something to return.
> That's why i've added the Thread.sleep method.

Yes, it should block, and sleeping will cause it to block.  But it still 
wakes up 4 times per second and runs a little bit of code.  It is not 
horrible, but it is also not necessary.

Using wait/notify, you can arrange for it to block until a character is 
actually placed into the queue.  That way, there is no overhead while you 
are waiting for input.

> You do have a valid point about dead-locking: the read() method
> is currently called from a non-AWT thread, so i'm safe here.
Yes, you are safe, but it would be a good idea to add the test.  The 
really neat thing about useful classes like the one you are writing is 
that you invariably find other uses for them, and so do other people.  
Usually this is long after you have forgotten all of the implementation 
details.  So if some time in the future, you or someone else tries to use 
it from the AWT thread, which would be better: a deadlock or an exception 
with an informative message?

-- 
John P. McGrath
<JPMcGrath@fast.net>
<jpm@nscs.fast.net>