5d930cadc8f62aee5f18e7921296fe66a54f18ab |
|
24-Apr-2014 |
Elliott Hughes <enh@google.com> |
Groundwork towards making the Libcore.os functionality public. Change-Id: Ie700aa16d91fba53fc5eb2555829cb74d84b12ad
|
b2e6be1cc1d375ca2fc28ee1fdfc10c0adc2554d |
|
29-Sep-2012 |
Elliott Hughes <enh@google.com> |
Rewrite NIO Pipe to use socketpair(2). Our Pipe originally used socket(2) to create AF_INET/AF_INET6 sockets. This was clearly a bad idea. I rewrote it to use socketpair(2) and AF_UNIX, but this was before the big "expose POSIX" rewrite, so it required a bunch of hacks in the native code, so I went with pipe(2) instead. The trouble with pipe(2) is that we end up using FileChannel to implement the Pipe.SinkChannel and Pipe.SourceChannel, but the kernel won't wake a read(2) on a pipe if another thread calls close(2) on it, so we started failing interrupt tests. This (final?) rewrite is hopefully the best of all worlds: we don't have any INTERNET permission needs, the code is as simple as the pipe(2) code, and interruption works. Bug: 7084342 Bug: 2735373 Bug: http://code.google.com/p/android/issues/detail?id=9431 (cherry picked from commit 3218082325b6b8713a8ac15731482e3da86a7df9) Change-Id: Ib92cdf8c818f6bba1f00e191f1b624ce9e693754
|
3218082325b6b8713a8ac15731482e3da86a7df9 |
|
29-Sep-2012 |
Elliott Hughes <enh@google.com> |
Rewrite NIO Pipe to use socketpair(2). Our Pipe originally used socket(2) to create AF_INET/AF_INET6 sockets. This was clearly a bad idea. I rewrote it to use socketpair(2) and AF_UNIX, but this was before the big "expose POSIX" rewrite, so it required a bunch of hacks in the native code, so I went with pipe(2) instead. The trouble with pipe(2) is that we end up using FileChannel to implement the Pipe.SinkChannel and Pipe.SourceChannel, but the kernel won't wake a read(2) on a pipe if another thread calls close(2) on it, so we started failing interrupt tests. This (final?) rewrite is hopefully the best of all worlds: we don't have any INTERNET permission needs, the code is as simple as the pipe(2) code, and interruption works. Bug: 7084342 Bug: 2735373 Bug: http://code.google.com/p/android/issues/detail?id=9431 Change-Id: If3f052c9d3f5aa1c099f5a069ace9a8d6ce3ca3a
|
d320e321d5567a4ac94b6e5874eda4b1f1189e13 |
|
30-Mar-2011 |
Elliott Hughes <enh@google.com> |
Move and rename an implementation detail. Change-Id: I563c2fd6689dd7249049671c3c01c6434d9b5fa5
|
41f0605d2c809bd9bc1c0fb68d86b49a0f59b6c5 |
|
24-Mar-2011 |
Elliott Hughes <enh@google.com> |
Add pipe(2). This lets us kill quite a bit of IoUtils. Bug: 3107501 Change-Id: Ic8a297b29cc53a17841cc77e266cd8dc3910c521
|
52724d3ebd4ccaaa4b9f5576e329d4272cde8ea9 |
|
17-Mar-2011 |
Elliott Hughes <enh@google.com> |
Add fsync(2) and fdatasync(2). Interesting parts to this change: * first BlockGuard support (and general delegation support). * first rethrowing of ErrnoException as IOException. * switching FileChannelImpl from int to FileDescriptor. The special case in FileDescriptor.sync has been removed. Testing with the RI showed that it doesn't treat syncing a FileDescriptor that corresponds to a socket as a special case --- it throws SyncFailedException just like normal. Bug: 3107501 Change-Id: I99faf120bd802aec0397a79772ed38c5e1542fed
|
6ab5999b58777725b4556e4d81bdec56b6d6c182 |
|
16-Mar-2011 |
Elliott Hughes <enh@google.com> |
Collapse the FileChannel implementations. This should be an (in)correctness-preserving transformation, with the exception of tryLock for read-only channels. Previously, that would unconditionally have been converted to a waiting lock, which seems like a bug. Bug: 3107501 Change-Id: Ief216c6f9f0a7dbe72f25c2fb63d983ec288f9a5
|
cdf7a1f942469221bcfd63d9cdf71851b011eaf0 |
|
16-Mar-2011 |
Elliott Hughes <enh@google.com> |
Expose POSIX constants. And use them, too. This patch is a little confusing because we already had constants in Java that were using the POSIX names but that didn't actually correspond to the constants whose names they'd stolen. Ugh. Bug: 3107501 Change-Id: Ib64a109c9340b0ecdf80bec91074206c001f455a
|
ae704b984c10a63883cc366e823d53902d6ac7a9 |
|
21-Sep-2010 |
Elliott Hughes <enh@google.com> |
Minor tidy-up. The nio implementation is still a bit of a mess because Java doesn't have any kind of "module" concept, nor "friend". But this makes it a little less untidy, and makes the deliberate access control subversions a little more explicit, and makes various things less accessible than they were. Change-Id: I514b1e24000b91f86b768ed408fedae115dc3080
|