[3279] in java-interest
Re: Reading information from a socket AND the keyboard -- A
daemon@ATHENA.MIT.EDU (Mike Afergan)
Sun Nov 5 23:35:16 1995
Date: Sun, 5 Nov 95 21:45:18 EST
To: java-interest@java.sun.com, gback@facility.cs.utah.edu
From: Mike Afergan <mikea@abba.ai.mit.edu>
Thanks for the advice, I guess that I was getting there. However, (even
after looking over your applet) I still have one problem. How does control
shift from one synchronized thread to the other?
Here are two scenarios that are both problematic:
1. My main thread/applet calls a thread that listens to the stream until
a new command is received. At that time it should shut down, somehow
leaving the main thread with the proper information. How easily can I alter
the variables in the main thread from the sub-thread? (I need to store the
information before I shut down.)
2. I will leave the sub-thread running for the lifetime of the applet.
In that case, how do I allow the paint() function to do its thing once new
information has been recieved. In this case I can refrence the variables in
the sub-thread from the main thread, but I have merely exchanged one problem
for another.
How should I resolve these problems? Which scenario is preferable?
Thanks for the help,
-- Mike
At 07:05 PM 11/5/95 -0700, gback@facility.cs.utah.edu wrote:
>[...]
> Am I perhaps missing a better solution?
>
>Perhaps. Just use a second thread, (have your applet implement
>Runnable, and define the run() method. This second thread will
>block on your socket connection. This is fine, since the first
>(main) will continue to process keyboard events.
>
>Now you need to structure your program so that the actions
>caused by input from your server are done by the 2nd thread
>that processes its input. Similarly, the first, main thread
>would execute the actions needed to react on keyboard input.
>
>If both threads share data structures, you need to put that
>access in a synchronized block.
>
>For an example, look at http://www.cs.utah.edu/~gback -> tetris.
>It doesn't use sockets, but employs a similar technique
>(one thread reacts on keyboard input to move pieces right or
>left, the other moves the piece down in regular intervals; look
>also at the use of synchronized)
>
> Godmar
>
>
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
