harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-6638) [classlib][nio]Some Selector behavior fixed.
Date Wed, 20 Oct 2010 16:04:27 GMT

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

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

Integrated in Harmony-1.5-head-linux-x86_64 #992 (See [https://hudson.apache.org/hudson/job/Harmony-1.5-head-linux-x86_64/992/])
    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.


Mime
View raw message