[95.12.01 -cj]

it appears that the java runitme schedules the wrong java Thread when SIGPOLL
occurs.

i have a basic telnet program which starts two threads. one to read the keyboard
and send that data to the socket, the other to read the socket and send data to the
screen. ideally, this should work just fine. however, there seems to be a problem
in the way threads get scheduled/awakened when both threads are read-blocked.

basically, when IO is available on one of the reads, the thread that is blocked on that
read does not necessarily get unblocked. the runtime always seems to unblock the
same thread, regardless of which thread had new data to read.

i experimented with thread priorities to see if that would make a difference -- it does!

when the keyboard input thread has higher priority,
the keyboard read thread runs (is scheduled) exclusively. data is read from the
keyboard and sent to the remote socket, but no echo/reply is read by the
network reader thread.

when both threads have the same priority, the problem is similar, once a steady state
is reached.

when the keyboard thread has a lower priority, the "correct" sequence of
SIGPOLL, getcontect, setcontext seems to occur.