Alexey Varlamov wrote:
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?
Hi,
The SIGUSR2 is much more powerful than I think. If it can really
break select operation without other harmful side-effect, I believe it
is a good way to Interrupt Channel.
IIRC, setInterruptAction is used if VM can not interrupt some I/O
blocking operation, like select(), so it set a callback and ask classlib
method to stop them(close fd, etc). But if SIGUSR2 works so well, I
doubt it is not necessary then.
BTW, can it break socket read/write or other blocking operation as
well? (I'm very interested in how does it work, as common thread
mechanism know nothing how to stop a certain I/O :) )
--
Alexey
2006/8/31, Paulex Yang <[EMAIL PROTECTED]>:
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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
