The close() may not be completely unsynchronized - the entire method isn't synchronized, but the implementation could still be locking within at certain critical points.
In any case, I'm not sure what the real guarantees of InputStream and BufferedInputStream should be. The spec is very quiet about the use in a concurrent use case. How much do we really need to guarantee? The original bug's test case seems overly contrived. Is there any real use case that this has shown up in? -Nathan On Fri, Nov 14, 2008 at 6:58 AM, Tim Ellison <[EMAIL PROTECTED]> 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. > >> 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 > >
