Name: nt126004			Date: 09/27/2002


FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]

ADDITIONAL OPERATING SYSTEMS :

A DESCRIPTION OF THE PROBLEM :
JDK 1.4 introduced the following check in PipedReader:

(in void receive(int c))

    else if (readSide != null && !readSide.isAlive()) {
            throw new IOException("Read end dead");


   The problem with this new code snipplet is that it makes
it impossible for multiple threads to share the same
PipedReader. For example, if one thread passes off the
PipedReader to another and shuts down, when the next thread
tries to make use of the pipe this exception will be thrown.

   I have one thread reading from the pipe while another
waits for the data for a TIMEOUT period of time. It's a
basic producer/consumer model. The problem is that multiple
producers share the same PipedReader (I spawn a new one per
read request) and the aforementioned exception is thrown.

    I understand that in my specific case I should
implement a more efficient use of Threads and try to make
use of a single thread for all producer operations, but
that is besides the point.

    I am wondering, why was this check added? Can we still
achieve the same functionality without this unwanted
limitation? If not, please document this limitation in the
Javadoc.

	I argue that "readSide" should be removed altogether and that users should be allowed to write into one end of the pipe even if there is no owner-thread over the other end. Reasoning: Users should be able to share 
PipedReader/PipedWriter across multiple threads; this is not possible in the current approach. If the old owner dies and the Piped* is 
passed on to another thread, an exception may *still* be generated complaining 
that the old thread is dead.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. See description
2.
3.

REPRODUCIBILITY :
This bug can be reproduced always.
(Review ID: 164393) 
======================================================================