harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@apache.org>
Subject Re: [drlvm] Use of SIGUSR2
Date Sun, 01 Mar 2009 21:26:40 GMT
On 2 March 2009 Mark Hindess wrote:
> In message <200903012137.37866.gshimansky@apache.org>, Gregory Shimansky
>
> writes:
> > On 1 March 2009 Gregory Shimansky wrote:
> > > On 1 March 2009 Mark Hindess wrote:
> > > > The latest issue on the "Problems with NIO" thread (message dated
> > > > Wed, 25 Feb 2009 23:09:49 +0100) seems to another case of a syscall
> > > > being interrupted by an internal SIGUSR2 and reporting an error that
> > > > needs to be caught and the signal retried.  There are already several
> > > > cases where the code "works around" this issue.  And *every*
> > > > occurence of affected syscalls[0] needs to be wrapped in this logic.
> > > >
> > > > The IBM VM doesn't do this kind of wrapping and I assume neither does
> > > > Sun's since all signals they receive are external and thus raising
> > > > the exception is the required behaviour.  I can't help thinking that
> > > > replacing the use of SIGUSR2 would be an easier option long term -
> > > > and better for performance - than wrapping every syscall.
> > >
> > > Actually if you strace Sun or Jrockit you would see tons of SIGUSR[1|2]
> > > (different VMs use different numbers) signals. There is even a special
> > > switch -XX:+UseAltSigs which allows Sun's VM to use signals other than
> > > SIGUSR for their internal use [1].
> > >
> > > I found other pages about signal usages by Sun's and BEA VMs [2][3][4].
> >
> > BTW BEA's page explicitly states that it is necessary to wrap all of the
> > syscalls with retry if there is EINTR. And since BEA's VM uses Sun's
> > classlib it means that all of the syscalls in Sun's classlib are wrapper.
>
> Gregory, thanks very much for the very informative response.  Seems like
> we need to audit classlib's use of the affected syscalls and fix them
> up.
>
> I didn't want to do this unless I was sure it was the right approach.

Well I never said that it is the right one, but it seems to be the most common 
one. IBM so far looks unique with not using signals and I wonder how they 
managed to avoid using them. Some kind of polling perhaps?

Anyway, if we decide to go on living with signals (wrapping syscalls with 
retry might also help living with other VMs) I think auditing class library 
native code is the right way.

-- 
Gregory

Mime
View raw message