Tim Ellison wrote:
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.
I just read the spec, it doesn't say the read method is synchronized or
thread-safe.
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?
I think BufferedInputStream just need to keep itself status consistent,
he never know how is the InputStream implemented, it's better to left
synchronous/asynchronous problems handled by the wrapped stream.
Best Regards,
Regis.
Regards,
Tim
