harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Zhou" <zhoukevi...@gmail.com>
Subject Re: [classlib][luni] BufferedInputStream can not be closed in another thread (HARMONY-6014)
Date Tue, 18 Nov 2008 02:21:23 GMT
I think Regis's suggestion, to shrink the synchronized block only on buff
object, is good, as for one aspect of performance improvement.
But we already confirmed that RI synchronizes its BufferedInputStream.read()
We have to follows the behaviors in the short terms to be compatible with

On Mon, Nov 17, 2008 at 6:42 PM, Regis <xu.regis@gmail.com> wrote:

> Tim Ellison wrote:
>> Regis wrote:
>>> I just read the spec, it doesn't say the read method is synchronized or
>>> thread-safe.
>> Agreed.  The class description doesn't say anything about multiple
>> threads.
>>  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.
>> Well at the moment we have the methods on BufferedInputStream marked as
>> synchronized.  That will ensure the consistency of the state in the
>> buffered stream, and in the wrapped stream.
>> Relaxing the sync on close() would pass through the multi-threading
>> problems to the wrapped stream, but we still need to ensure the buffered
>> stream is consistent, and that is non-trivial too (see my patch on the
>> JIRA).
> I think The consistency of wrapped stream should be assured by itself,
> BufferedInputStream should be transparent on this. But I tested, that RI
> also synchronized the read method. So if we follow RI, I think the patch may
> be the best solution.
> Best Regards,
> Regis.
>> Regards,
>> Tim

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message