1) There's no reason or way to support boot_clock for waiting for
property changes, since the underlying futex_wait uses
CLOCK_MONOTONIC. We probably wouldn't want boot_clock even if it
did, since it doesn't make sense to consider the time a device was
suspending in the timeout for waiting for a property to change.
2) The init tokenizer has been essentially unchanged for a decade,
there's no motivation to 'fix' it to not require a trailing
newline.
3) The ueventd TODO regarding moving vendor specific ueventd.rc
entries out of rootdir has been fixed.
Test: n/a
Change-Id: I3b68e3d2f25cbd539f9f8ff526669b8af04d833d
Copy bionic's CachedProperty with some minor API tweaks, to allow for
efficient querying of properties that rarely change.
Bug: http://b/141959374
Test: treehugger
Change-Id: I4dfc3f527d30262b35e871d256cec69e69f2e1d7
Also change the properties implementation to call the new API. We use
this ParseBool API in the new SystemProperties implementation, with
which we want the libbase property API to be consistent.
Test: included
Change-Id: I89cb3eb4e1203a6bb0da41914dad720e44c00303
Since 'struct timespec' members (time_t and long) are both 32bit on
32bit systems, and std::chrono::{seconds,nanoseconds}::rep are both
>32bit, timespec members assigned in DurationToTimeSpec() can have a
negative value, especially when WaitForProperty() is called with the
default timeout value which is std::chrono::milliseconds::max().
Regarding functionality, passing a negative value to
__system_property_wait() is okay because WaitForProperty() still
waits for the property value (so unit tests are passing), but while
WaitForProperty() does that, the function, to be more exact,
SystemProperties::Wait() in bionic/, consumes ~100% of CPU time. This
happens because SystemProperties::Wait() which implements
__system_property_wait() has a tight while-loop with a __futex_wait()
call, and the futex call immediately returns EINVAL when the timespec
passed in has a negative value.
With this CL, WaitForProperty() will never pass a negative timespec
to __system_property_wait(), and therefore the __futex_wait() call
in bionic works as expected without consuming too much CPU time even
on 32bit systems.
Bug: None
Test: libbase_test32 still passes
Test: strace no longer shows repeated EINVALs from __futex_wait
Change-Id: Id1834fac8cd2876b02dbe4479bf3d3eda2fa7da1
This is needed if they will ever handle ro. properties that have
values longer than 92 characters.
Bug: 23102347
Bug: 34954705
Test: read and write properties with value length > 92 characters
Change-Id: I44aa135c97ec010f12162c30f743387810ae2c5d
std::chrono doesn't handle integer overflow, so using
std::chrono::milliseconds::max() to indicate an infinite timeout is
not handled well in the current code. It causes an 'absolute_timeout'
earlier in time than 'now' and causes the associated WaitForProperty*
functions to return immediately.
Also, any duration_cast from relative_timeout to nanoseconds would
cause the same issue, as it would overflow in the conversion and
result in an invalid results.
This change prevents any duration_casts of relative_timeout to
nanoseconds and replaces the logic to wait on an absolute timeout with
logic that compares the time elapsed to the provided relative timeout.
This change also includes a test that std::chrono::milliseconds::max()
does not return immediately and that negative values do return immediately.
Test: Boot bullhead + libbase_test
Change-Id: I335bfa7ba71e86c20119a0ed46014cad44361162
- unlike base::WaitForProperty, which waits for specific value to
be set, this one only waits until the property is created.
bug: 35178781
Test: added unit test
Change-Id: Idbf98c2152fe768357302f6b69310c55305f5d54
Also adapt libcutils to the bionic change that was necessary for this.
Bug: http://b/35201172
Test: ran tests
Change-Id: I72a98b70b03d23e958b46778b505fbd5c86c32ae
Makes it easier to write correct code in a world where the maximum
property key/value lengths change.
Bug: http://b/23102347
Test: libbase_test64
Change-Id: I100f00904221bbcef9e8786a4e6e30428039bb49
Tom Cherry