harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Artem Aliev" <artem.al...@gmail.com>
Subject Re: [classlib][luni] signalis interruptus in hysock
Date Wed, 18 Oct 2006 10:46:32 GMT
Geir,

I create HARMONY-1904 issue for this case.

Thanks
Artem

On 10/17/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>
>
> Artem Aliev wrote:
> > Gier,
> >
> > I'd like to resurrect this topic.
>
> Oh goody!
>
> > We try to run JBoss on Harmony and meet the same problem.
> >
> > Here is an except from the stack trace:
> > java.net.SocketException: The call was cancelled
> >        at
> > org.apache.harmony.luni.platform.OSNetworkSystem.availableStreamImpl(OSNetworkSystem.java)
> >
> >        at
> > org.apache.harmony.luni.platform.OSNetworkSystem.availableStream(OSNetworkSystem.java:216)
> >
> >        at
> > org.apache.harmony.luni.net.PlainSocketImpl.available(PlainSocketImpl.java:150)
> >
> >        at
> > org.apache.harmony.luni.net.SocketInputStream.available(SocketInputStream.java:50)
> >
> >        at
> > com.mysql.jdbc.util.ReadAheadInputStream.available(ReadAheadInputStream.java:212)
> >
> >        at com.mysql.jdbc.MysqlIO.clearInputStream(MysqlIO.java:774)
> >
> >
> > Actually, my old patch (attached) fix this problem too.
> > So could you please take a look at the patch one more time
> > or implement your fix for the availableStreamImpl() and other
> > functions that call
> > hysock_select().
>
> Yes - that was something on my list.  I knew that first iteration was
> incomplete, but wanted to wait to see what happened.  I still don't
> agree that those low level calls should simply swallow the EINTR, but
> let the higher levels in our 10,000 layer stack :) decide what to do.
>
> >
> > Thanks
> > Artem
> >
> > PS:
> >> And one other comment on the proposed patch...  it doesn't respect the
> >> timeout as it restarts the select() with the original timeout..
> > #> man select
> >
> >      On Linux, the function select modifies timeout to reflect the
> > amount of time not slept; most  other  implementations  do  not  do
> >       this.   This  causes  problems  both  when  Linux code which
> > reads timeout is ported to other operating systems, and when code is
> >       ported to Linux that reuses a struct timeval for multiple
> > selects in a loop without reinitializing it.  Consider  timeout  to
> > be
> >       undefined after select returns.
> >
> > PPS: FYI: the comments and revision for previous fix.
> >
> >
> > svn log modules/luni/src/main/native/luni/shared/socket.c
> >
> > r441311 | geirm | 2006-09-08 04:51:36 +0400 (Fri, 08 Sep 2006) | 12 lines
> > modifications to hysock_select() to report when
> > interrupted, and then in pollSelectRead() in
> > socket.c for linux only to handle the
> > interrupt return code.
> >
> > This passes all tests and also fixes the problem
> > with tomcat.  I'd like to continue with the other
> > uses of hysock_select() in socket.c and elsewhere
> > but want to commit to let others review before
> > I go further
> >
> >
> > On 9/7/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> >> And one other comment on the proposed patch...  it doesn't respect the
> >> timeout as it restarts the select() with the original timeout...
> >>
> >>
> >>
> >> Geir Magnusson Jr. wrote:
> >> >
> >> >
> >> > Weldon Washburn wrote:
> >> >> On 9/1/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> >> >>>
> >> >>>
> >> >>>
> >> >>> Artem Aliev wrote:
> >> >>> > The hyport and hy* are a porting layer that provides os independent
> >> >>> > interface.
> >> >>> > hysock_select() does not return EINTR on windows why it should
> >> do it
> >> >>> > under linux?
> >> >>> > either user presses Ctrl-c or ctrl-\ or VM uses other signals
> >> for its
> >> >>> > owns needs.
> >> >>>
> >> >>> I think you just gave me the answer.
> >> >>>
> >> >>> The *caller* to hysock_select() needs to decide what to do on
> >> EINTR, not
> >> >>> hysock_select() itself.
> >> >>>
> >> >>> I still don't think this is a perfect solution, but I think it's
> >> >>> better :)
> >> >>
> >> >>
> >> >> Does the above solve the problem completely or is it a temporary
> >> patch?
> >> >
> >> > I don't know, but happy to call it a temporary patch - right now we're
> >> > stuck, because we can't even run tomcat and I want to do a new
> >> snapshot.
> >> >
> >> >> Will the caller to hysock_select() need to have "#ifdef Windows....
> >> >> #ifdef
> >> >> Linux..."?
> >> >
> >> > We already have platform specific code that calls hysock_select()
> >> >
> >> > geir
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >
> > ------------------------------------------------------------------------
> >
> > --- modules/luni/src/main/native/port/linux/hysock.c
> > +++ modules/luni/src/main/native/port/linux/hysock.c
> > @@ -2570,11 +2570,16 @@ hysock_select (struct HyPortLibrary * po
> >    I_32 rc = 0;
> >    I_32 result = 0;
> >
> > -  result =
> > +  do
> > +  {
> > +    result =
> >      select (nfds, readfds == NULL ? NULL : &readfds->handle,
> >              writefds == NULL ? NULL : &writefds->handle,
> >              exceptfds == NULL ? NULL : &exceptfds->handle,
> >              timeout == NULL ? NULL : &timeout->time);
> > +  }
> > +  while (result == -1 && errno == EINTR);
> > +
> >    if (result == -1)
> >      {
> >        rc = errno;
> >
> >
> > ------------------------------------------------------------------------
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message