JDK 10 RFR of 8185092: Data race in FilterOutputStream.close

[Martin Buchholz]

Looks good to me.

I again forgot that VarHandles are still only whitelisted for
java.util.concurrent.

I would label this noreg-hard .

On Wed, Jul 26, 2017 at 11:33 AM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> On Jul 26, 2017, at 11:25 AM, Martin Buchholz <martinrb at google.com> wrote:
>
> Making close exactly-once as you have done is probably the right strategy.
>
> Probably most of java.io was designed to be "mostly thread-safe" as was
> common culture back in the last millennium.  There were no "synchronized"
> in FilterOutputStream probably because previously there was no need!
>
> For jdk10 VarHandles are probably generally preferred to j.u.c.atomic
> classes.
>
>
> A blanket change from atomics could be a separate issue.
>
> The lack of thread safety specs (and general java.io love) remains a long
> term big problem.
>
>
> I noticed your issue comment; this should be filed as another issue, I
> suppose.
>
> It's weird to add @bug to a test without changing the test itself.  Is the
> test really testing this fix?
>
>
> Yes, it’s weird. It’s not really testing the fix. I was thinking of this
> change as correcting the patch which fixed the issue linked to this issue
> which uses the same test. I would actually prefer not to modify the test
> and instead add the label “noreg-cleanup” as this change seems to be pretty
> clear.
>
> Thanks,
>
> Brian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20170726/22aad809/attachment-0001.html>