harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Regis <xu.re...@gmail.com>
Subject Re: [classlib][luni] BufferedInputStream can not be closed in another thread (HARMONY-6014)
Date Mon, 17 Nov 2008 04:25:46 GMT


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
> 
> 

Mime
View raw message