harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [classlib][luni] signalis interruptus in hysock
Date Thu, 31 Aug 2006 10:43:22 GMT

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.


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

View raw message