harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Zhang" <zhanghuang...@gmail.com>
Subject Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Date Sun, 18 Jun 2006 00:28:37 GMT
On 6/18/06, Archie Cobbs <archie@dellroad.org> wrote:
> Andrew Zhang wrote:
> > if thread A is block on ServerSocket.accept(), then A is interrupted by
> > another thread. What should be the result?
> > Spec says "If none of the previous conditions hold then this thread's
> > interrupt status will be set. "
> > Only interrupt status should be set and thread A should keep
> blocking!  RI
> > also behaves in this way.
> > Therefore, I'm not sure whether signal communicatoin works for this
> > scenario.
> If you wakeup from accept() with a signal, and you want to ignore that
> signal, you just loop back and invoke accept() again (same would be true
> for any other interruptible system call like read, etc.). Instead, if you
> need to throw some exception, you throw it. Etc.

Oh... Got it, thanks, Archie.

One more question: Where does these code locate? In begin/end method or main
body between begin/end?
Not only Selector, SocketChannel, ServerSocketChannel but also any class who
extends AbstractInterruptibleChannel are interruptible channel. Any
interruptible channel could use begin/end to mark a blocking I/O operation.
How do I know which interruptible system call should be invoked again? Who
keeps the call stack trace?

> If a signal is sent to one thread, then the target is really "killed".
> Only for certain signals like TERM, INT, etc. If we were to use signals
> for interrupt, we'd use one of the user-defined signals like USR1 and
> then install a signal handler which ignored the signal (i.e, just
> returned).
> > But interrupt concept in java.lang.Thread is not the same as that in
> native
> > OS. For java, the interrupted thread ends its lifecycle in some
> situations
> > while it keeps the same as if no interrupt happens except that the
> > interrupt
> > status is set  in other situations.
> > Comments? Please correct me if I'm missing something. Thanks!
> Not sure what you mean by "ends its lifecycle".. if you mean returns from
> whatever method was being invoked, yes sometimes it returns and sometimes
> it does not.. but either way can be implemented as described above.

Agree. If signal handler may loop back and invoke the method again. But see
my question above. :)

> __________________________________________________________________________
> Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com
> ---------------------------------------------------------------------
> 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

Andrew Zhang
China Software Development Lab, IBM

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message