harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: Problems with NIO
Date Tue, 24 Feb 2009 08:35:29 GMT

In message <200902240803.n1O83fXh016687@d06av01.portsmouth.uk.ibm.com>,
Mark Hindess writes:
>
> 
> In message <5948b71e0902232318i3b733ed8p24fd274a4af73e45@mail.gmail.com>,
> Charles Lee writes:
> > 
> > Hi Niklas,
> > Thanks for your testing code. I have run it on the linux and
> > reproduced the error. After some investigation, I find something
> > really confused me: when poll in the NetworkInterfaceLinux.c line
> > 300, we encounter a system interrupt call. This is where the socket
> > exception from.
> >
> > Anybody has encountered this? or is there somewhere some code will
> > interrupt the thread?

FYI: drlvm uses SIGUSR2 for GC or something so interrupts will be common on
this VM.  The IBM VME doesn't do this so while it would have the problem it
would remain hidden until someone uses signals for something in there 
application.

> > By the way, I have read some code in the file: NioSocketAcceptor,
> > AbstractPollingIoAcceptor to see what is acctually doing when bind
> > an address, only to find that MINA first select the Selector then
> > register the Selector. That seems strange for me.
>
> I can see a number of issues with the native code too.  The
> windows implementation of selectImpl returns an error code from
> a portlib function (hysock_select).  This makes sense because it
> allows the Java code to correctly test to see if the result is
> ERRORCODE_SOCKET_TIMEOUT.
> 
> However, the unix implementation returns the result of a native poll
> call which is not then mapped to the platform independent portlib
> error code so will always return -1.  This must be wrong.  The
> unix implementation should be fixed to return the correct platform
> independent error codes.  Then the implementation can be fixed to
> return (HYPORT_)ERROR_SOCKET_INTERRUPTED which the Java code can check
> for and avoid throwing the exception.
> 
> I'll take a look at fixing the native code.

I've checked in a quick fix (including a fix for the java code which
might not be idea) at r747301.  Comments welcome on improving the fix.

Niklas, many thanks for reporting this and producing a concise test
case.  Let us know if the next snapshot doesn't show improvement and if
you find any more issues.

Regards,
-Mark.



Mime
View raw message