| 4af0d8c99d68bcacff182699527d983a1d34fdbe |
|
28-Mar-2011 |
Elliott Hughes <enh@google.com> |
Support read-only ByteBuffers.
Buffer.array() and Buffer.arrayOffset() throw for read-only buffers. We need
to work round this. We know that this is safe because we trust ourselves not
to write to read-only buffers and because all non-direct buffers have a
backing array.
Bug: 3107501
Change-Id: I501a5f7ddba2c66d22864bf4a41b927263493293
|
| 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
|
| 0f335c4ed1a0cb419c8ce82183fabb241d5dd032 |
|
07-Sep-2010 |
Elliott Hughes <enh@google.com> |
Kill getEffectiveAddress.
Set the corresponding field in the constructors.
Requires a dalvikvm change: https://android-git.corp.google.com/g/64866
Bug: 2935622
Change-Id: I26663bfcdb80db75672be71395b861c1a79c24fc
|
| c73a5be50cdd804ff3c12e7b43da08c33cdd6f21 |
|
04-Sep-2010 |
Elliott Hughes <enh@google.com> |
Move some of the nio implementation into java.nio.
Another stepping-stone to simplifying the PlatformAddress/OSMemory situation.
Bug: 2935622
Change-Id: Ic5b941ee7c17d6b5aeda53c3c2cdf2c43cebff55
|