Regis wrote: > Tim Ellison wrote: >> The new code is quite gross -- I really wonder what the use case is that >> means close() should be unsynchronized?? > > One thread block on read, another one want to close the stream > immediately, if read and close are both synchronized, the second one > would be blocked until the first one read something.
I understand the hypothesis, but why would you have a blocking read and non-blocking close? The buffer input stream wraps an underlying stream, it doesn't make sense to me to make it part synchronized and part not. > I think, here the question is why we synchronized the whole read method. As you showed, the read method in the RI is synchronized. We are trying to be compatible -- otherwise we'd just leave the close method synchronized. > Holding one lock and blocking on IO is dangerous, especially holding > "this" lock. Could we use private lock for synchronizing buffer? 'dangerous'? It keeps things consistent, since you can't as for available() or close() during a read(). Are you suggesting we deliberately deviate from compatibility in this case? Does anyone rely upon the "asynchronous" close behavior? Regards, Tim
