harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [classlib][luni] signalis interruptus in hysock
Date Thu, 31 Aug 2006 06:23:36 GMT
Guys,

Probably I missed that thread on InterruptibleChannel implementation,
but I've just hit on the following code in
java.nio.channels.spi.AbstractInterruptibleChannel:

static {
try {
	setInterruptAction = AccessController
	.doPrivileged(new PrivilegedExceptionAction<Method>() {
		public Method run() throws Exception {				return
Thread.class.getDeclaredMethod("setInterruptAction",			new Class[] {
Runnable.class });
		}
	});
	setInterruptAction.setAccessible(true);
} catch (Exception e) {
	// FIXME: be accomodate before VM actually provides
	// setInterruptAction method
	// throw new Error(e);
}
}

There are no docs on j.l.Thread.setInterruptAction()... Does this code
snippet relate to the subject of this discussion?

--
Alexey

2006/8/31, Paulex Yang <paulex.yang@gmail.com>:
> Geir Magnusson Jr. wrote:
> > Time to take another run at this since I didn't get any responses on
> > the drlvm thread.
> >
> > We have the problem that DRLVM uses SIGUSR2 in the thread manager (not
> > an unreasonable thing to do, I believe) but this results in knocking
> > threads out of select() in hysock.c (and I'm sure we'll see it in
> > other places.)
> >
> > Now, I'm not sure what the right course of action is.  We have a
> > suggested patch from Artem that suggests we just ignore when the tread
> > is interrupted :
> >
> > --- 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;
> IIRC, months ago similar approach was discussed in another thread for
> j.nio.channels.InterruptibleChannel implementation, but IMHO it can be a
> workaround but is not acceptable as a solution, because
> InterruptibleChannel is extensible by user application, i.e., user can
> implement their own interruptible blocking I/O easily without
> considering too much on thread sync issues, it's not reasonable to ask
> user writing codes within a loop like this.
> >
> >
> > this works, but I'm bothered by the fact that we're just blindly
> > ignoring signals like this.  I also think that I need to go and do
> > this everywhere we have a non-restarted interruptable blocking system
> > call.
> >
> > Now, I'd like to get this fixed today, as it's high time for another
> > snapshot of the JRE and HDK, but w/o it, Tomcat runs for 2 seconds at
> > best :)
> >
> > So - does anyone have any other bright ideas?  Why don't we see this
> > with J9?    Would it be better to do a per-thread signal mask after
> > asking the thread manager what signal it's using du jour?  (Andrey
> > noted that Sun allows one to change the signals used, apparently to
> > prevent collision w/ user code vi JNI, I guess...)
> >
> > 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
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
> ---------------------------------------------------------------------
> 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