Skip to content

GitLab

Switch branch/tag
  1. 07 Jun, 2012 2 commits
  3. 02 Jun, 2012 2 commits
  5. 03 May, 2012 2 commits
  7. 02 May, 2012 2 commits
  9. 01 May, 2012 2 commits
  11. 23 Apr, 2012 2 commits
    • Keun-young Park's avatar
      Merge "Modify the behavior of test. It always test in en_US, and it will test... · 4c432afd
      Keun-young Park authored 
      Merge "Modify the behavior of test. It always test in en_US, and it will test in en_IN when en_IN is available."
      4c432afd
    • Masanori Ogino's avatar
      Avoid a wavy result for InterruptReadable/WritableChannel test · 3ec5e434
      Masanori Ogino authored 
      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
      3ec5e434
  13. 20 Apr, 2012 2 commits
  15. 19 Apr, 2012 1 commit
    • Jean-Baptiste Queru's avatar
      Simplify and speed up makefile. · 2e7fae93
      Jean-Baptiste Queru authored 
      No need to shell out just to find 2 makefiles that very rarely change.

As an added bonus, this fixes a bug that appears when the cd command
actually prints some output, which it does when certain
environment variables are set.

Change-Id: Iab7a738c2ca62f3c591c3bf1f47b70407b90e99a
      2e7fae93
  17. 25 Mar, 2012 1 commit
  19. 16 Feb, 2012 1 commit
  21. 14 Feb, 2012 1 commit
  23. 07 Feb, 2012 2 commits
  25. 03 Feb, 2012 2 commits
  27. 01 Feb, 2012 1 commit
  29. 31 Jan, 2012 2 commits
  31. 30 Jan, 2012 4 commits
  33. 27 Jan, 2012 1 commit
  35. 26 Jan, 2012 2 commits
  37. 23 Jan, 2012 1 commit
  39. 21 Jan, 2012 1 commit
  41. 20 Jan, 2012 1 commit
  43. 19 Jan, 2012 1 commit
  45. 08 Dec, 2011 1 commit
  47. 29 Nov, 2011 1 commit
  49. 22 Nov, 2011 1 commit
    • JP Abgrall's avatar
      libcore: BlockGuard: untag socket on close · 4ff58546
      JP Abgrall authored 
      java.net.Socket creates the socket on connect(). But in case of failure
during the connect() it closes the socket.
During the create, BlockGuard's socket() is the one tagging the socket.
But in case of failure, nobody untags that socket.
So now we untag scokets on close() in BlockGuard

Bug: 5274621
Change-Id: I282665a05e2dc184df77c84ceab49fb55b7695af
      4ff58546
  51. 13 Nov, 2011 1 commit