harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrey Chernyshev" <a.y.chernys...@gmail.com>
Subject Re: [drlvm] problem when TM patch applied
Date Wed, 23 Aug 2006 15:25:39 GMT
On 8/23/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> Artem Aliev wrote:
> > Gier,
> >
> > The DRLVM uses SIGUSR2 in thread suspend algorithm.
> > hysock_select() returns EINTR error when the signal appears, and
> > Socket.accept() throws exception.
> >
> > The New ThreadManager use thread_suspend() more extensively ( in lock
> > reservation algorithm). So the problem appears more frequently.
>
> Excellent - I knew there had to be an explanation as to why the same
> symptom appears so much faster...
>
> >
> > Following patch to hysock.c fixes the problem in hysock.
> > Probably classlib experts could provide better way to fix this problem.
> >
>
> This seems wrong - that we're going to make it everyone else's problem

The other way we can look at this as if the DRLVM was an arbitrary
user application code which is utilizing SIGUSR2 for some reason.
In this case the hysock implementation appears to be not immune to
such user code.


> because we're using SIGUSR2.  Is there a way to setup a handler such
> that select() (and other things scattered about, including user native
> code) don't have to worry about this?

I think that DRLVM correctly installs the SIGUSR2 handler with the
SA_RESTART flag which means that the interrupted function should be
restarted.
It looks like the actual problem here is that the select()
implementation on Linux is not restartable (POSIX says this is up to
specific select() implementation whether to restart or not).
This can be workarounded in the hysock.c in a way that Artem suggested.

Note that the reference VM is also using SIGUSR2 for it's internal
purposes in the default configuration (see
http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/java.html), so
the DRLVM doesn't imply any additional restrictions on the user's code
from this point of view.
We may need, however, to add a command line option proposing usage of
the alternative signals similar to what RI does.

Anyways, it might be good if we can make the hysock implementation
more robust wrt signals.


Thanks,
Andrey.

>
> Thanks for nailing this so quickly.
>
> geir
>
> > --
> > Artem Aliev, Intel Middleware Products Division
> >
> > --- 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
>
>


-- 
Andrey Chernyshev
Intel Middleware Products Division

---------------------------------------------------------------------
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