harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anton Luht" <anton.l...@gmail.com>
Subject Re: [classlib][luni] signalis interruptus in hysock
Date Thu, 31 Aug 2006 12:50:13 GMT
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.

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


-- 
Regards,
Anton Luht,
Intel Middleware Products Division

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