harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Hindess (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-6312) Concurrency problems in NIO
Date Mon, 21 Sep 2009 08:34:15 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12757850#action_12757850

Mark Hindess commented on HARMONY-6312:

A long time?  You commented on the dev list on Sept 11th so it's only been a little over a
week.  It took you 12 days (between Aug 27th and Sept 8th according to JIRA comments) to come
up with the patches so allowing others at least that much time is not unreasonable.

I read the commit messages and I had read the patches so I know what you committed but your
commit messages didn't mention the names of the patches (you used the 'Subject:' from the
patch I think) you committed which would make it easier for others to follow.

However, the main problem I have is with respect to the origin of the work you are committing.
 In commit r817167, you applied your patch (0001...patch) which makes it look like your work
but this change comes entirely from the patch Jesse contributed so in reality it is his work.
 I would prefer (for the benefit of the project if we ever need to defend our work) that commits
more accurately reflect the origins of the code being committed.

> Concurrency problems in NIO
> ---------------------------
>                 Key: HARMONY-6312
>                 URL: https://issues.apache.org/jira/browse/HARMONY-6312
>             Project: Harmony
>          Issue Type: Bug
>          Components: Classlib
>         Environment: SVN Revision: 801399
>            Reporter: Jesse Wilson
>            Assignee: Regis Xu
>         Attachments: cancelledkey.diff, NIO_Concurrency_issues.patch, selector.zip
>   Original Estimate: 72h
>  Remaining Estimate: 72h
> There's several potential concurrency problems in our NIO implementation...
>  - Charset#isSupported isn't synchronized, but it accesses mutable member cachedCharsetTable.
>  - In SelectionKeyImpl, stHash++ is a non-atomic operation so multiple SelectionKey instances
may receive the same hash code. (Why not use the default hash code?)
>  - In SelectorImpl, the unmodifiableKeys member is never synchronized on. But the documentation
specifies that clients can synchronize on that set to guard against changes
> These are the obvious problems; I suspect there are more subtle concurrency defects at
play here. I'll prepare a patch to address the major issues, and we should consider a rigorous
approach (Findbugs?) to discover concurrency problems.
> #Android

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message