| f0d40d662d9dfdb04215c718961765837d2cf00c |
|
11-Apr-2014 |
Neil Fuller <nfuller@google.com> |
libcore changes to support asynchronous close interruption
Previously AsynchronousSocketCloseMonitor was used to handle
socket interruption on close. To support the same for
FileChannel it has been renamed to AsynchronousCloseMonitor.
The Java class was already called this.
FileInputStream, FileOutputStream, RandomAccessFile will
now throw IOException if a connection is closed by another
thread during read. Thread.interrupt() continues to have no effect
on streams.
FileChannel will now throw AsynchronousCloseException during
reads and writes if the file is closed, per the documentation.
FileChannel will now throw ClosedByInterruptException during
reads and writes if the thread reading/writing is interrupted.
Note: FileChannel.lock() will probably still not not throw
AsynchronousCloseException, though it probably should.
This change also has impact on external/conscrypt and
frameworks/base.
Change-Id: I37de3e7d1a005a73821221e6156d10b95c595d7a
Bug: 13927110
|
| 9726be51ed6f9695357bc8f11a547d9beaa79fce |
|
16-Oct-2012 |
Brian Carlstrom <bdc@google.com> |
Fix Thread.interrupt and PipedInputStream/PipedReader issues found by InterruptedStreamTest
Bug: 6951157
Change-Id: I558f8eb5c435f01c98c080ac38cc7c165e7aee25
|
| 243111f8533820ea8d27bde6317f88f610aa5867 |
|
16-Oct-2012 |
Brian Carlstrom <bdc@google.com> |
Fix flakiness with InterruptedStreamTest DO NOT MERGE
Bug: 6951157
Change-Id: I4a23a90a4a54d71f9cc5f0c608a30000c8e1b033
|
| 3ec5e434af58fedddcb34e08dbd021bfb78bc69c |
|
17-Apr-2012 |
Masanori Ogino <ogino.masanori@sharp.co.jp> |
Avoid a wavy result for InterruptReadable/WritableChannel test
Currently Thread#interrupt() API cannot interrupt (just close fd)
even if a thread is blocking in I/O operation for an InterruptibleChannel.
In other words, if a thread is blocked by read()/write() operation,
then the Thread#interrupt() from another thread will close fd,
but it cannot interrupt the blocking operation of Channel.
In this test case, if the calling sequence is interrupt() -->read()/
write() (actually it occurs on many dual core ICS devices),
then the test passes. Because the fd has already been closed.
However, if the order of the calling sequence would change to
read()/write() --> interrupt(), the test fails (i.e, I/O operation
will not return). It occurs on a device which has a single core
processor. Indeed, if I change the test case by adding sleep()
before interrupt() then it fails on Galaxy Nexus.
The blocking call stack is below;
at libcore.io.Posix.readBytes(Native Method) <-- BLOCKED!
at libcore.io.Posix.read(Posix.java:113)
at libcore.io.BlockGuardOs.read(BlockGuardOs.java:144)
at java.nio.FileChannelImpl.readImpl(FileChannelImpl.java:294)
at java.nio.FileChannelImpl.read(FileChannelImpl.java:278)
at java.nio.PipeImpl$PipeSourceChannel.read(PipeImpl.java:89)
at libcore.java.io.InterruptedStreamTest.
testInterruptReadableChannel(InterruptedStreamTest.java:133)
...
So the test should be wait before interrupting the current thread
in order to avoid a wavy result for these test cases.
They will pass after the interruption of blocked operation
in Channel is implemented correctly.
And also I correct a wrong method call from
testInterruptWritableSocketChannel().
Change-Id: Iaae3128d264070e818dc82d831ea8048bb43ad4a
|
| 63f7b99a47b05e0f85308fbf9697f7c678a47345 |
|
05-Oct-2011 |
Jesse Wilson <jessewilson@google.com> |
Remove tests that always time out.
Bug: http://b/5410725
Change-Id: I116e5a846a528899608895163bb2a27573c5efae
|
| 1f3a0774e666448ceff2b8f2eebdee0e5e69a561 |
|
16-Aug-2011 |
Jesse Wilson <jessewilson@google.com> |
Don't leave the thread's interrupted bit set.
This was causing tests to fail under CTS.
Change-Id: Iaefa292321c77ca1644fc04655d6c9aa1cac9b88
|
| 9ad09702f665937ec727de97d41d7854ee352ce0 |
|
22-Apr-2011 |
Jesse Wilson <jessewilson@google.com> |
Test for Thread.interrupt() plus IO.
Change-Id: I831caf3984bbdda55beadfaae910050363aa5ed5
http://b/4181738
|