[4919] in java-interest
Solaris System.in.read() and threads...
daemon@ATHENA.MIT.EDU (Pat Niemeyer)
Mon Jan 22 15:51:42 1996
Date: Sun, 21 Jan 1996 13:16:11 -0600 (CST)
From: Pat Niemeyer <pat@icon-stl.net>
To: java-interest@java.sun.com
Ok, I know that time slicing in threads is implementation dependent, but
shouldn't blocking on a read from a stream always cause a thread
to yield control? Under Solaris its seems to depend on what kind of stream.
Blocking on System.in.read() seems to keep the thread in
a "runnable" state and does not give up control to the next thread. Whereas
blocking on a read() from a socket does yield control to the next thread
in the expected round-robin way.
Is this a bug or a defined difference?
The following code will block on the Foo thread forever. If you change the
read() to be a read() from a socket inputstream, it will yield control
and only become runnable when there is data to be read. The latter is the
behavior that I would expect.
What's the deal?
Thanks
(Note that if you run this on Win95 the time slicing will work around the
problem)
//------------------------------------------
import java.net.*;
import java.io.*;
class main {
public static void main( String args [] ) {
new Foo().start();
new Bar().start();
}
}
class Foo extends Thread {
public void run() {
while ( true ) {
System.out.println("Foo");
try {
System.in.read();
} catch ( Exception e ) {};
}
}
}
class Bar extends Thread {
public void run() {
while ( true ) {
System.out.println("Bar");
yield();
}
}
}
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
