harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <ndbe...@apache.org>
Subject Re: [classlib][luni] BufferedInputStream can not be closed in another thread (HARMONY-6014)
Date Sat, 15 Nov 2008 02:44:23 GMT
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 <t.p.ellison@gmail.com> 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
>
>

Mime
View raw message