Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <1830528128.1253523138358.JavaMail.jira@brutus>
Date: Mon, 21 Sep 2009 01:52:18 -0700 (PDT)
From: "Regis Xu (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=12757851#action_12757851 ] 

Regis Xu commented on HARMONY-6312:
-----------------------------------

> 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.
Agree, the patch named by what it did, but it still helpful to point out the exact name in commit message.

> 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 mentioned that in JIRA comments,  and I never claim they are my work. I apologize for not clarifying it in commit message.

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


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