You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Hudson (JIRA)" <ji...@apache.org> on 2010/10/20 16:56:24 UTC

[jira] Commented: (HARMONY-6638) [classlib][nio]Some Selector behavior fixed.

    [ https://issues.apache.org/jira/browse/HARMONY-6638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922989#action_12922989 ] 

Hudson commented on HARMONY-6638:
---------------------------------

Integrated in Harmony-select-1.5-head-linux-x86_64 #144 (See [https://hudson.apache.org/hudson/job/Harmony-select-1.5-head-linux-x86_64/144/])
    Back-out part of change from revision 1002476 (fix for HARMONY-6638) that checks if the key is connected before OP_CONNECT is added to the list of selected keys.  Adding a test that registers an OP_CONNECT key on a socket channel, connects and then checks there's a key in the selectedKeys() list passes on the RI (also removing the check doesn't cause the regression test that was added for 1002376 to fail).


> [classlib][nio]Some Selector behavior fixed.
> --------------------------------------------
>
>                 Key: HARMONY-6638
>                 URL: https://issues.apache.org/jira/browse/HARMONY-6638
>             Project: Harmony
>          Issue Type: Bug
>          Components: Classlib
>    Affects Versions: 5.0M14
>            Reporter: Li Jing Qin
>            Assignee: Li Jing Qin
>            Priority: Critical
>         Attachments: HARMONY-6638.diff
>
>
> There are some problems with harmony Selector:
> 1. When a serversocket channel does not bind anything, selector should return acceptable. In this situation, poll return POLLHUP. I add this flag to the native code.
> 2. The same as 1, when a socketChannel does not connect any anything, selector should return connectable. In this situation, poll return POLLHUP, I also add this flag to the native code.
> 3. As the spec said, selector should also return if an error occurred. I'm not testing the error condition, but I add POLLERR to the native code.
> 4. If user change the interested operations of a selector, this selector should treated as a new one (but with the same SelectionKey). On the other hand, if the selector was return once and no interested operation changed, it should not be selected next time. I have add a flag stateChange in the SelectionKeyImpl to save this state.

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