Nathan Beyer wrote: > 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?
Right, the spec is not helpful here. Regis' test case does look contrived, and I don't think we have a real world example of when an asynchronous close() is required, but I can imagine that it would be true for socket input streams. Again, a contrived case, but imagine that you got an input stream from a URLConnection, and wrapped it in a BufferedInputStream. You could be blocked on the read() in one thread, and decide to close() the stream in another... Regards, Tim
