the open source release. This was only used in tests that never ran
as part in the open source release.
PiperOrigin-RevId: 636167506
Change-Id: Iafc33bd768307fe9ee77b181369635012abf2245
proposed standard pthread_cond_clockwait() and sem_clockwait().
These are currently implemented in glibc >= 2.30.
These methods take a clock and use an absolute time with reference
to that clock, so KernelTimeout now can produce these values.
PiperOrigin-RevId: 522824226
Change-Id: Ife98713f6f95d800b1f8e52d5364a3dbebc4f8a6
Windows tests often run in Emulation, and even with KVM we can still timeout.
PiperOrigin-RevId: 517192968
Change-Id: I3b4e435f8ac8ad1e7eab6f043c051fa75efed64b
timeouts, but when a relative timeout is provided, the timeout is an
absolute timeout against a steady clock (when possible). This allows
methods that return relative timeouts to automatically recompute the
remaining duration, for instance, on suprious wakeups.
PiperOrigin-RevId: 516304139
Change-Id: I7d739cb50dd749eba5dba7ac6c34d18dc53703ed
std::chrono methods used by std::condition_variable.
A followup change will add an implemention of
synchronization_internal::Waiter that can use
std:mutex/std::condition_variable to implement the per-thread
semaphore that absl::Mutex waits on. This implementation may at some
point become the default on platforms such as Windows where there
doesn't seem to be an easy way of supporting real absolute timeouts. In
this case we can defer to their standard library to implement correct
support.
PiperOrigin-RevId: 510204786
Change-Id: Icf4d695013fd060abbd53dae23e71ea36f731565
APIs that take KernelTimeout as a parameter can now query if an
absolute or relative timeout was requested. If the underlying API can
only use one type of timeout, the code will do a reasonable
conversion.
The goal is to eventually enable the possibility of using wait times
that are based on monotonic clocks that are safe against system clock
steps.
PiperOrigin-RevId: 508541507
Change-Id: Id08bf13515f3e1bfd78d88393cde98a6fd3ef72c
