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 Fri, 01 Sep 2006 13:35:21 GMT


Alexey Varlamov wrote:
> 2006/8/31, Geir Magnusson Jr. <geir@pobox.com>:
>>
>>
>> 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.
> 
> I'm not an expert in pthreads, but why not use pthread_sigmask[1]
> then? Just block SIGUSR2 before select() and unblock/reset upon
> return. Better yet, first ask a VM if it uses any signals internally
> like DRLVM does, and then block those if any. This requires minor VMI
> extension, though.
> 
> [1] int pthread_sigmask(int how, const sigset_t *set, sigset_t *oset);
> (see http://www.opengroup.org/onlinepubs/007908799/xsh/sigprocmask.html)

Yes, I've been suggesting that one for a week now.  Great [or demented] 
minds think alike, I suppose.  My problem is that I have no experience 
using this technique, and I don't always trust unix APIs :)

I guess before we go down that path, I'd like to once again appeal to 
our brethren from IBM or elsewhere to tell us either that J9 doesn't use 
signals (or they are very clever with them), and how or why.

geir

> 
> -- 
> Alexey
> 
>> 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
>>
>>
> 
> ---------------------------------------------------------------------
> 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