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 13:12:45 GMT


Anton Luht wrote:
> Hello,
> 
> Behaviour of select() with SA_RESTART can vary by platform - see [1]
> 
> ---quote begins----
> [EINTR]
> The select() function was interrupted before any of the selected events
> occurred and before the timeout interval expired. If SA_RESTART has been 
> set
> for the interrupting signal, it is implementation-dependent whether 
> select()
> restarts or returns with [EINTR].
> ---quote ends----
> 
> Thus, I think Artem's patch is correct - it just make behaviour of
> select() not dependent on the underlying platform - the call is
> restarted just like read() and write() do.

Hmmm.

Artem's patch does it for all signals.  You can set the sighandler to 
SA_RESTART on a *per signal* basis.  So there's a difference.  I'm not 
sure if it's a meaningful difference, but it's there.

geir


> 
> [1] http://www.opengroup.org/onlinepubs/007908799/xsh/select.html
> 
> On 8/31/06, Geir Magnusson Jr. <geir@pobox.com> 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: 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