harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Zhang" <zhanghuang...@gmail.com>
Subject Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.
Date Wed, 12 Jul 2006 02:51:05 GMT
Hi Mikhail,

It's a NON-NLS message.

Native code is designed in this way. Currently, Harmony socket native code
uses messages in SocketException to identify error type.

To avoid the confusion, two alternatives way I could image are:

1. Native code returns platform-independent error code.

2. Native code throws different exceptions, which are all extended from
SocketException.

Anyway, as current Harmony native design, the message in SocketException
thrown by native code is a NON-NLS string, that is to say, like "GET","POST"
in http protocol.  Unless we take a big change on native code design, I
don't think the code is dangerous.

What's your opnion?

Best regards,
Andrew


On 7/11/06, Mikhail Loenko (JIRA) <jira@apache.org> wrote:
>
>    [
> http://issues.apache.org/jira/browse/HARMONY-815?page=comments#action_12420281]
>
> Mikhail Loenko commented on HARMONY-815:
> ----------------------------------------
>
> Hi Andrew
>
> I think it's rather dangerous:
>
>        }  catch (SocketException e) {
>            if (ERRMSG_NONBLOKING_OUT.equals(e.getMessage())) {
>                return sendCount;
>            }
>            throw e;
>
> Once we internationilize our code that won't work
>
> > [classlib][nio] Refine implConfigureBlocking(boolean) method of
> DatagramChannel and SocketChannel.
> >
> --------------------------------------------------------------------------------------------------
> >
> >          Key: HARMONY-815
> >          URL: http://issues.apache.org/jira/browse/HARMONY-815
> >      Project: Harmony
> >         Type: Improvement
>
> >   Components: Classlib
> >     Reporter: Andrew Zhang
> >     Assignee: Mikhail Loenko
> >  Attachments: nio.diff
> >
> > Currently, Harmony DatagramChannel.implConfigureBlocking(boolean) does
> nothing.
> > It doesn't cause any problem of read operation because Harmony uses
> select+blocking read to ensure nonblocking reading.
> > But it affects write operations, although it is difficult to test the
> difference between blocking write and blocking write.
> > Another defect is introduced by portlib bug. As discussed on mailing
> list[1], connect_with_timeout always changes the fd to blocking mode after
> invocation.
> > I'll upload a patch to fix these problems.
> > Thanks!
> > Best regards,
> > Andrew
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
>   http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
>   http://www.atlassian.com/software/jira
>
>


-- 
Andrew Zhang
China Software Development Lab, IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message