Tim Ellison wrote: > Geir Magnusson Jr wrote: >> Paulex Yang wrote: >>> I'm trying to complete the interruptible channel feature of NIO module, >>> but there is a question. >>> >>> The spec for InterruptibleChannel says: >>> >>> "A channel that implements this interface is asynchronously closeable: >>> If a thread is blocked in an I/O operation on an interruptible channel >>> then another thread may invoke the channel's close method. This will >>> cause the blocked thread to receive an AsynchronousCloseException. >>> >>> A channel that implements this interface is also interruptible: If a >>> thread is blocked in an I/O operation on an interruptible channel then >>> another thread may invoke the blocked thread's interrupt method. *This >>> will cause the channel to be closed, the blocked thread to receive a >>> ClosedByInterruptException, and the blocked thread's interrupt status to >>> be set. * >> Why exactly would one want the channel to be closed? This seems like >> something you'd want to leave up to the thread or some other entity that >> owns the channel. I find it weird that channel lifecycle is a side >> effect like this. > > If the thread (and therefore the IO operation) is interrupted then the > underlying channel will be left in an unknown state -- the only > reasonable action you can take in such circumstances is to close it.
Given that you are blocked, why is it in an unknown state? Doesn't the channel know that it didn't complete what it was trying to do? geir > > Regards, > Tim > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
