On Aug 31, 2006, at 3:03 AM, Jimmy, Jing Lv wrote:
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 :) )
Yes, it's one of the 'features' of signals in unix. So read() and
write() are also affected - they can return from a blocking operation
with nothing read and errno set to EINTR.
SIGUSR2 is not in itself any more powerful than SIGUSR1 - they all
have the same effect, namely a software interrupt.
I looked in DRLVM and it appears that the right thing is being done -
namely the sighandler is being setup w/ the SA_RESTART flag, so that
system calls that can be restarted are restarted. Experimentation on
ubuntu shows that read() can be dealt with this way, but select()
doesn't appear to be able to... IOW, I can get it so signals are
caught and handled and read() is automatically restarted - it doesn't
complete on the signal and therefore never appears to me to be
interrupted, where I cant' get select() to behave that way.... it
always completes when a signal is caught.
This is consistent with Stevens, although he notes that in SVR4,
select() is restarted. :/ Of course Stevens is pre-linux, and still
talks about modems. It's truly a great reference for this, but would
be nice if it was up-to-date wrt linux. The problem is that the
author died a few years ago...
So I don't know what to do. I'm hoping someone can tell us how J9
does this - the obvious answer is that J9 doesn't use any signals,
but I'm not sure if I buy that yet.
If we employ the patch, then our socket listening code can't be
interrupted, and I'm pretty uncomfortable with that.
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
