harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [classlib][luni] signalis interruptus in hysock
Date Fri, 01 Sep 2006 13:17:18 GMT
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)

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


Mime
View raw message