<div dir="ltr">On a desktop or server the difference between the realtime and monotonic<br>clocks doesn't matter much, but we've seen cases on Android where<br>something's run under timeout(1) but killed before it's had a chance to<br>do anything because the device went into sleep shortly afterwards and by<br>the time it came back, the timeout had elapsed (as far as the realtime<br>clock is concerned) but the process had only had a tiny fraction of the<br>timeout where the system wasn't suspended.<br><br>This patch also adds an xparsetimespec() function; at this point the<br>only remaining users of xparsetime() are in lib, so maybe that should<br>become static, at least until we have another need for it?<br><br>A bigger question is whether timeout(1) needs to offer the user a choice<br>between the two different clocks? Although monotonic is usally the right<br>default choice on Android, and I don't have a specific counter-example<br>to hand, I can imagine that someone might actually mean "wall clock time"<br>rather than "cpu clock time" when setting a timeout...<br><br>Luckily, timer_create() lets us trivially choose between both clocks<br>if so.<br>---<br> lib/lib.h            |  1 +<br> lib/xwrap.c          |  4 ++++<br> scripts/make.sh      |  2 +-<br> toys/other/reboot.c  |  6 +++---<br> toys/other/timeout.c | 29 ++++++++++++-----------------<br> toys/posix/sleep.c   |  6 +++---<br> 6 files changed, 24 insertions(+), 24 deletions(-)<br></div>