geir
>
> [1] http://www.opengroup.org/onlinepubs/007908799/xsh/select.html
>
> On 8/31/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>>
>> 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]
>>
>>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
