Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <1951047230.1253522055992.JavaMail.jira@brutus>
Date: Mon, 21 Sep 2009 01:34:15 -0700 (PDT)
From: "Mark Hindess (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Commented: (HARMONY-6312) Concurrency problems in NIO
In-Reply-To: <686258648.1250542154851.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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