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.
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.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
